LINUX.ORG.RU
ФорумAdmin

Linux и файловые системы xfs,jfs,ext4,btrfs,squashfs.

 ,


0

1

приветствую глубокоуважаемого Олла.

Нарыл себе толстый USB диск и произвел некоторые эксперименты и замеры.
Исходное состояние 600Gb раздел. Форматировал его/их в btrfs,jfs,xfs,ext4
Затем делал rsync. Длительность операции порядка 11 часов для 500Gb при скорости копирования порядка 15Мб/с.

/dev/vol 600G 487G 114G 82% /opt/pub.usb (btrfs:compress)
/dev/vol 591G 492G 70G 88% /opt/usb.p3 (ext4)
/dev/vol 600G 492G 109G 82% /opt/pub.usb (jfs)
/dev/vol 600G 495G 106G 83% /opt/pub.usb (xfs)

Размеры немного различаются (делалось в разное время) однако тенденцию видно:
ext4 отъедает места больше всех. По сравнению с xfs,jfs пропадает порядка 40Гб
btrfs с опцией compress дает еще 5Gb однако на более другом разделе данные более другие:
На разделе по данным du -sh = 564G данных, при этом по df -h Он показывает что занято 507Gb. Итого экономия 57Gb на упаковке, с xfs этот раздел не сравнивал. Долгое это занятие - rsync такого объема данных.

В ходе экспериментов btrfs не раз вставал в режим когда часть файлов не читалась. Перезагрузка исправляла ситуацию.
jfs при аварийном завершении всегда не монтировался и требовал длительной починки.
xfs и btrfs пока нормально монтируются при аварийной потере питания.
До кучи еще исполнял: #/usr/bin/time du -sh Users (занимает 128Gb)
На разных фс оно дало:
btrfs 6:52.00elapsed 21%CPU
squashfs 0:25.32elapsed 98%CPU
ext4 3:09.06elapsed 8%CPU
jfs 3:43.20elapsed 8%CPU
xfs 2:28.41elapsed 11%CPU
Рекордсменом тут как видите выступает squashfs, но оно read-only (Ну раз измеряем стоит отметить что раздел паковался по данным /usr/bin/time: 29:40:12elapsed 34%CPU)
т.е. 486Gb Данных mksquashfs ужал практически за 30 часов до 358Gb сэкономив 128Gb
Самым тормозным оказался рекордсмен по размеру: btrfs
xfs самый быстрый из фс и мало расходующий на свои нужды.
Были нарекания на надежность, но тут может спасти лишь бэкап, для любой из ФС - абсолютно надежных FS нет, впрочем как и носителей.

★★★

Последнее исправление: cetjs2 (всего исправлений: 1)

USB диск

Дальше можно не читать. Единственное на что это годно — выдергивать диск в различные не подходящие моменты (имитация сбоев по питанию) и смотреть как выживает ФС.

sdio ★★★★★
()

Вывод то какой?
Можешь запостить в ЖЖ

user0
()

однако на более другом разделе данные более другие:

Тест на моск: Мой моск сломан. Учи русчасть.

cinyflo ★★★★★
()
Ответ на: комментарий от sdio

Сбои по питанию.

Сбои по питанию были увы не только у диска, у всей системы.
Интересовала еще и производительность.
И емкость.
В древней машинке большого диска нет для измерений.
Хотите читайте, хотите нет. Я замерил и положил.
В случае чего могу сослаться на свои замеры в обсуждениях.

n0mad ★★★
() автор топика
Ответ на: комментарий от cinyflo

Моск.

Другой раздел содержит другие данные, пакуются они более по другому. К сожалению не нашел команды для принудительной перепаковки btrfs раздела дабы убедиться что все правильно.
На одном разделе 600Gb экономия 5Gb
на другом 120Gb
Именно потому и привел цифры с другого раздела.
К сожалению не нашел как средствами btrfs посмотреть/посчитать статистику упакованного раздела.

n0mad ★★★
() автор топика
Ответ на: комментарий от sdio

USB диск.

Появилось сегодняшнее дополнение:
На разделе 1.282.316 файлов.
#du -sh ext4 |tee -a pub.ext4.out 2>&1
495G ext4
3.62user 23.80system 36:24.38elapsed 1%CPU (0avgtext+0avgdata
7888maxresident)k
2207280inputs+8outputs (1major+4365minor)pagefaults 0swaps

Аж Тридцать шесть минут.

Впрочем только сейчас заметил косяк.
В предыдущих тестах была папка Users а тут весь раздел.
Впрочем раз в пару недель делаю рсинк этого раздела на другой сервак с рейдом из 3 IDE и 2 SATA Винтов по 160. В итоге имеем 600Gb раздел с xfs.
Его результаты:
491G xfs
3.32user 27.23system 15:11.97elapsed 3%CPU (0avgtext+0avgdata
8080maxresident)k
1064592inputs+0outputs (1major+4454minor)pagefaults 0swaps

Не 36 а 15 минут.

Через Х дней синкну на xfs другой раздел (тот который хорошо упаковал btrfs) и померяю его производительность.
Однако я в шоке: rsync с btrfs на xfs раздел работает со скоростью порядка МЕГАБАЙТА в секунду. В 15 раз медленнее чем обычно.
Вечером домой доберусь и посмотрю результаты. Если оно так и будет 1Mb/s то синк будет длиться 11*15=165 часов... (неделю).

btrfs явно не продакшн, особенно с упаковкой.

Такие вот очередные результаты. Возможно они никому и не нужны, но время потрачено и результаты надо где то запечатлеть. Если у кого вдруг возникнут такие вопросы, возможно они нагуглят это и увидят ответы.

n0mad ★★★
() автор топика
Ответ на: комментарий от sdio

бить молотком по нему в различные неподходящие моменты (имитация ударов молотком) и смотреть как выживает ФС.

смол фикс

TC, xfs на внешнем винте - экстрим, сжатие 0.5терабайта данных - утопия. Такое на практике используется где-нибудь?

backbone ★★★★★
()
Ответ на: комментарий от sdio

Внешние винты роняются также часто, как и выдёргиваются, чем не тест...

Пропускная способность USB сведет на нет разницу в шустрости ФС

squashfs 0:25.32elapsed 98%CPU

Вот этот тест показывает, что USB не является узким местом.

backbone ★★★★★
()
Последнее исправление: backbone (всего исправлений: 1)
Ответ на: комментарий от sdio

Конечно, нужно на SSD делать тесты, жалкие нищеброды из положья которые не могут позволить отвалит 100 килорублей за 1тб SSD.

bhfq ★★★★★
()
Ответ на: USB диск. от n0mad

Отзываю наезды на btrfs.

«Дело было не в бобине» Пришел вечером, за весь день 15Gb синкнулось и iowait 40%
Тупо остановил комп (poweroff), USB hdd и запустил заново. Синкается все со стандартной для этого устройства скоростью. 15чтения и одновременно 15 запись. gkrellm показывает скорость USB диска до 30Mb/s

n0mad ★★★
() автор топика
Ответ на: комментарий от sdio

Тебя "прет" от того что других оскорбляешь?

Если ты богат, богатство твое может быть краденным.
А честные люди в этом мире и «нищебродишки» потому что чужого не берут.
Богатенькие тут не те кто своим трудом, а кто с чужого труда стрижет.
Жизнь вообще дело случая, рраззз - секунда, и богач станет нищим
А здоровяк - дохляком.

n0mad ★★★
() автор топика

xfs всем хорош, но как его не настраивай сам, какие новшества линус в ядро не всовывай, на маленьких файла это тормоз. Порробуй удалить сорцы ядра на разделе с xfs, раз в пять медленнее чем даже с ext3

sergeto5markov
()
Ответ на: комментарий от sdio

Приношу свои извинения.

Я немного не въехал откуда пошло.

n0mad ★★★
() автор топика
Ответ на: комментарий от sergeto5markov

xfs

Скорости это отдельный разговор. Не будем его касаться.
Мои аргументы:
1. btrfs: появляются нечитаемые файлы до перезагрузки. Система после этого не шатдаунится. Наблюдал это на 2х разделах.
2. jfs: При некорректном завершении (повисание btrfs, потеря питания) не монтируется, требует fsck - достаточно длинного.
3. ext4: Большие потери места.

Наконец мой выбор:xfs - Малые потери места, после некорректного завершения монтируется. Работает пока без нареканий

n0mad ★★★
() автор топика
Ответ на: xfs от n0mad

Меня как раз скорость интересует. Мерял скорость копирования-перемещения на brtfs, так она ну очень не торт, в сравнении с ext* и xfs. Мерял также время открытия прог, также больше. Про jfs ничего не скажу, ни разу не пробовал. Место при нынешних дисках, это не самый сильный аргумент, скорость и безопасность важнее, а тут brtfs айтсайдер (кстати о безопасности xfs тоже много писали не слишком лестного)

sergeto5markov
()
Ответ на: комментарий от nanoolinux

Куда его девать, в музей криминалистики ? :-) Поддержка в ядре только левыми патчами, а третья версия вообще не имеет никаких преимушеств

sergeto5markov
()
Ответ на: комментарий от nanoolinux

Рейзер и иже с ними.

Тестил то что имеется в репозитарии сквиза.
# mkfs <TAB>
mkfs mkfs.cramfs mkfs.ext4 mkfs.minix mkfs.reiser4
mkfs.bfs mkfs.ext2 mkfs.ext4dev mkfs.msdos mkfs.vfat
mkfs.btrfs mkfs.ext3 mkfs.jfs mkfs.ntfs mkfs.xfs

# dd if=/dev/zero of=file.dat bs=1048576 count=100
# mkfs.reiser4 file.dat -f
# mount file.dat a -o loop
mount: unknown filesystem type 'reiser4'

Рейзер пока не осилил. Интересует то что работает «ис каропки». Ведь на внешнем hdd и кто знает куда меня с ним занесет. Хотя конечно ходят слухи что у рейзера и упаковка есть.

всех благ,
Олег.

n0mad ★★★
() автор топика
Ответ на: комментарий от sergeto5markov

скорости/безопасность.

Так есть померянные мною примитивные результаты.
Про безопасность разговор отдельный - бэкапиться надо. Везде есть ошибки.
jfs - продукт от фирмы ibm, думаю достаточно мозгов приложено при планировании архитектуры ФС.
С xfs по скорости тоже не айс. Было дело - пользовал на 2Tb разделе. Через год работы сервера он минутами открывал каталоги. Уж не знаю как он их фрагментировать умудрялся. Каталоги с регулярно добавляющимися файлами. Впрочем давно это было, лет 5 назад.
Сейчас дома сделал xfs партиции. Вот сегодня всю ночь лилось 500Gb с btrfs на xfs, утром встал но оно еще льется. Ушел на работу. После переливки запущу примитивные тесты типа #/usr/bin/time du -s </mountpoint> Покажу и размер и время исполнения тут. ext4 вон меня порадовал 36 минутами. Заодно посмотрим free получившегося раздела по сравнению с пакующим btrfs.

n0mad ★★★
() автор топика
Ответ на: комментарий от tid

-m0

Спасибо за наводку.
Совсем забыл про резерв под рута.
Кстати может подскажешь?
Другие ФС имеют резерв под рута?

n0mad ★★★
() автор топика
Ответ на: скорости/безопасность. от n0mad

Добавка на тему btrfs vs xfs

Одни и те же данные синкнуты на физически одинаковые 600Gb разделы форматированныу xfs и btrfs. btrfs Монтировалась с упаковкой.

Размер данных 567G
$df кажет:
xfs 600G 568G 33G 95%
btrfs 600G 507G 94G 85%

du Выполняется с временем:
xfs du: 6:58.94elapsed 10%CPU
btrfs du 14:52.04elapsed 22%CPU

find $1 ! -type d 2>&1 |wc -l
Файлов 2426571 - выполняется со временем:
xfs 6:18.67elapsed 13%CPU
btrfs 20:44.93elapsed 17%CPU

Делайте выводы :)

всех благ,
Oleg

n0mad ★★★
() автор топика
Ответ на: Добавка на тему btrfs vs xfs от n0mad

Добавка на тему btrfs vs xfs vs ext4

Обновление отчета, приведу полностью чтобы не приходилось скролиться сравнивая.
Есть 2 толстых раздела, и вот уже не первый день играю в игру:
«I like to move it, move it»
Одни и те же данные синкнуты на физически одинаковые 600Gb разделы форматированны xfs,btrfs,ext4. btrfs Монтировалась с упаковкой.

Размер данных 567G
$df кажет:
xfs 600G 568G 33G 95%
btrfs 600G 507G 94G 85%
ext4 591G 568G 0 100%

При этом у ext4 Есть полезная фича: 5% диска по умолчанию резервируется на процессы исполняющиеся от имени root. В итоге если юзеры забили диск под 0 на 600Gb остается еще 30Gb места для рута. Однако при всем этом финально на этом разделе на xfs уместилось на 10Gb больше данных чем на ext4. Оверхид у ext4 все же выше.

du Выполняется с временем:
xfs - 6:58.94elapsed 10%CPU
btrfs - 14:52.04elapsed 22%CPU
ext4 - 6:19.28elapsed 11%CPU

find $1 ! -type d 2>&1 |wc -l
Файлов 2426571 - выполняется со временем:
xfs 6:18.67elapsed 13%CPU
btrfs 20:44.93elapsed 17%CPU
ext4 5:43.03elapsed 13%CPU

Делайте выводы :)

всех благ,
Oleg

n0mad ★★★
() автор топика
Ответ на: комментарий от mm3

Картина писалась для Linux - ntfs и vfat тут лишние.

С другой стороны - зачем картине быть полной?
Картина должна показывать видение автора и не более, иначе это уже не картина, а назовем «обзор».

Резюмирую видение:

ext4 - мэйнстрим, и не зря. На моих примитивных тестах показывает лучшие результаты. То что накладные расходы места на 1.5% поболее xfs - не смертельно.

xfs - Все замечательно, но не заметил фичи - резерва пространства для рута имеющегося в ext4

squashfs - Самый производительный. В принципе с помощью aufs можно сделать r/w пакованный вариант. Игрался в свое время.

jfs - Работает без нареканий, использовал много. Однако btrfs,ext4,xfs журналирующие ФС могут монтироваться без проверки ФС после некорректного завершения а вот jfs требует fsck.

btrfs - Разрабатывающаяся как высоконадежная и пакующая ФС, однако замечено что после нескольких дней работы файлы перестают читаться до ребута. При этом отмонтировать нечитающуюся ФС и перезагрузиться штатно не получается.

Итак: в большинстве случаев следует использовать ext4. Другие ФС не имеют каких то существенных преимуществ видных сразу.
С другой стороны тестирование было не полным - не хватает тестов на производительность скажем SQL сервера на разных ФС и как сильно будут тормозиться растущие базы (насколько эффективны механизмы сопротивления фрагментации использующиеся в современных ФС.
Встречался с реализацией программ ведущих в SQL базах журналы демонов, соответственно получаем пачку стабильно растущих баз и через некоторое время - они получаются сильно фрагментированными, так что простейшие выборки длятся секундами.

всех благ,
Олег.

n0mad ★★★
() автор топика
8 января 2013 г.

Простите, что пишу в такую старую тему. Дело в том, что ext4 создает иноды при создании ФС, и, как мне кажется, он их создает просто ДОХРЕНА, и именно они отжирают место. mkfs.ext4 -N позволяет задать количество инодов. У меня, например, на / и /home вместе всего 5.8 млн. инодов, используется 260 тыс. инодов. Для дисков, на которых планируется хранение больших файлов, вроде фильмов, музыки, хватит 1-2 млн. инодов, а ext4 по умолчанию вам сделает около 15 млн. на 600 гб.

У xfs создание инодов автоматическое, про другие ФС не знаю.

ValdikSS ★★★★★
()
Ответ на: xfs от n0mad

| Наконец мой выбор:xfs

лорчую!

Если в следующий раз соберёшься тестить на 3ГБ home под кучу мелких конфигов, не забудь про reiserfs.

d ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.