Форум OlegON > Компьютеры и Программное обеспечение > Операционные системы и программное обеспечение > Linux

Сравнение устойчивости файловых систем к сбоям по питанию : Linux

28.03.2024 17:16


27.03.2019 22:25
OlegON
 
Сравниваю EXT4, XFS, JFS

Сделал просто три раздела соответствующих и одновременно стал лить во все три раздела в один файл с добавлением. Дернул питание. Все файлы нулевые, на каждой из файловых систем. Отмечу, что на JFS автоматом не отработал fsck и сам раздел не примонтировался. Кстати, по производительности JFS лидировала.

Изменил скрипт, который теперь небольшую фразу стал заливать в файлы с номерами одновременно на все ФС.

Код:
#!/bin/bash
for i in {1..500000}
do
   echo "Welcome $i times jfs" > /mnt/jfs/test$i.txt
done
31492 files - EXT4
31363 files - JFS
31196 files - XFS

но скрипты генерации запускались как раз в обратном порядке, так что тут, можно сказать, все одинаковы... Дернул питание. Опять JFS автоматом не починилась.

Код:
[root@box2 xfs]# find test* | wc -l
28518
[root@box2 ext4]# find test* | wc -l
31082
[root@box2 jfs]# find test* | wc -l
31363
тем не менее, видим, что на JFS больше всего файлов уцелело, однако, на всех файловых системах много файлов с нулевой длиной

Код:
[root@box2 jfs]# find test* -empty | wc -l
156
[root@box2 xfs]# find test* -empty | wc -l
896
[root@box2 ext4]# find test* -empty | wc -l
3203
Упс... После удаления пустых файлов (find -empty -delete)

Код:
[root@box2 ext4]# find test* | wc -l
27879
[root@box2 xfs]# find test* | wc -l
28518
[root@box2 jfs]# find test* | wc -l
31207
Что-то я архивы на JFS хочу перенести...
27.03.2019 22:28
baggio
 
Получается jfs более производительная а не надёжная...
27.03.2019 22:40
OlegON
 
Код:
find ./ext4 -name test* | wc -l
459846
find ./xfs -name test* | wc -l
160526
find ./jfs -name test* | wc -l
500000

find test* -empty -delete

find ./jfs -name test* | wc -l
499997
find ./ext4 -name test* | wc -l
447333
find ./xfs -name test* | wc -l
151584
erase and rewind...

Код:
find ./jfs -name test* | wc -l
274658
find ./ext4 -name test* | wc -l
138365
find ./xfs -name test* | wc -l
99695

find . -name test* -empty -delete

find ./jfs -name test* | wc -l
274213
find ./ext4 -name test* | wc -l
136352
find ./xfs -name test* | wc -l
96544
27.03.2019 22:41
OlegON
 
Цитата:
baggio Получается jfs более производительная а не надёжная...
не понял... вот как раз провел второй эксперимент, без вывода числа записей в момент создания файлов... не только более производительная, но и более надежная.
28.03.2019 07:47
OlegON
 
Код:
rsync atest(~500M) /FS/atest

ls -la ./jfs
total 1408292
drwxr-xr-x  2 root root        40 мар 28 07:42 .
drwxr-xr-x. 5 root root        53 мар 28 07:38 ..
-rw-------  1 root root 510784896 мар 28 07:42 test1.txt
-rw-------  1 root root 510784896 мар 28 07:42 test2.txt
-rw-------  1 root root 420515840 мар 28 07:42 .test3.txt.f005nd

ls -la ./ext4
total 773112
drwxr-xr-x  3 root root  15966208 мар 28 07:42 .
drwxr-xr-x. 5 root root        53 мар 28 07:38 ..
drwx------  2 root root     16384 мар 26 21:28 lost+found
-rw-------  1 root root 510784896 мар 28 07:42 test1.txt
-rw-------  1 root root 264896512 мар 28 07:42 .test2.txt.2T8RPy

ls -la ./xfs
total 0
drwxr-xr-x  2 root root  6 мар 28 07:42 .
drwxr-xr-x. 5 root root 53 мар 28 07:38 ..
10.04.2019 11:37
OlegON
 
В общем, добавил к тестированию BTRFS, тормозная страшно, если сравнивать с другими.
Да, про проверку при загрузке я, конечно, ступил выше. В fstab во флагах должно стоять 0 2, почему-то все, кроме JFS это игнорировали и проверялись.
Что сделал - 100М файл одновременно и параллельно копировал на точки монтирования с разными файловыми системами 50 раз в разные файлы, потом читал их в /dev/null, потом стирал, писал название файловой системы, потом копировал этот же файл в 100 разных файлов. В момент, когда все потоки успевали вывести название файловой системы, т.е. переходили в длинный этап, с небольшой задержкой рубил питание, делая Force reset виртуалке. Тест повторял несколько раз, каждый раз очищая оставшиеся от предыдущего теста файлы.

Сделал для себя неожиданные открытия. Во-первых, понятно, в ext4 все файлы не влезали (каждая точка монтирования была 10Гб и 100 файлов, соответственно, влезали только при набивании под завязку), поскольку там резерв, но они не влезали и в btrfs... Причем, даже со сжатием. Совершенно не понял прикола с тем, что если cp не могла записать файл по нехватке места, он создавался нулевого размера. И на ext4, и на btrfs. Во-вторых, когда добавил удаление и чтение, самой медленной системой стала ext4. Внезапно. Причем, тормозить стала так, что отставать от остальных систем стала настолько, что те успевали записать другие файлы длинного этапа. Это синоним слову "чудовищно". В лидеры вышла... тадам-м-м, XFS. Но это по скорости. Что мне крайне не понравилось, это то, что сравнивая файлы по размеру, я на XFS один раз увидел поврежденный файл, например, 85, т.е. 84 и 86 были по 100Мб, 87 и далее - нулевого размера, а 85, например, 70Мб. Видимо, сработала параллельная запись данных, точнее, один поток не успел записать что-то. Т.е. надо понимать, что повреждение может быть не только последнего файла. Хотя именно такое поведение предсказывали для JFS, JFS как раз за таким замечена не была.

Во время монтирования поврежденных файловых систем дольше всего проверялась JFS, но это "дольше" длилось секунды три. Остальные вообще незаметно отрабатывали. За время опытов ни одна система не развалилась совсем. Лечились и были готовы работать дальше.

Попробовал ext4 c data=journal, думал, тут она вообще неубиваемой станет. Ну... Как сказать... Нулевые файлы пропали, да. Работать стала просто адски долго. Т.е. перехода к длинному этапу я вообще едва дождался. Остальные все отработали. Те файлы, что записались полностью, были на месте. Файл, на котором дернул питание - огрызком. Собственно, у большинства систем результат почти такой же, только с некоторым отставанием. Т.е. последние несколько файлов были пустыми, а до них файл-огрызок. Учитывая скорость работы ext4 в таком режиме, сомнительное преимущество.

Если дергал питание в скором времени после того, как все потоки отработали, на всех файловых системах файлы были целыми.

В целом, если часто дергают питание, рекомендую поставить UPS :) если защищаться от сбоев, то, у меня складывается мнение, что юзерам я буду ставить JFS (себе на ноут при следующем смене системы, например). Пишет она быстрее и с меньшими потерями при неожиданном выключении. У жены, кстати, на ноуте, живет и несколько нештатных выключений уже пережила. На сервере и для хранилок, судя по всему, лучше XFS нет файловой системы. JFS тут проигрывает по скорости чтения и удаления, а еще червоточинкой сидит какое-то исследование 2005 года, настаивающее, что из-за способа записи метаданных файлы могут пропадать неограниченно по времени записи. Не очень понимаю такую формулировку но боюсь :)
08.10.2019 21:57
OlegON
 
В общем, спалил тут, что жена уже достаточно долгое время выключает ноут, просто выдергивая кабель из розетки при перемещениях. Из-за стационарного использования батарейка уже давно сдохла, потому комп рубится. Так вот, хвала JFS, пока все еще живо. Хотя хром с кучей закладок вечно что-то пишет.
09.10.2019 07:05
OlegON
 
Всем бы хороша, но у меня везде Fedora, а это - постоянное обновление ядра, при том, что ZFS стоит отдельно и ее модуль ядра надо собирать отдельно.
Кеш, опять же, отдельно... При ребуте проверка не запустится автоматом, надо scrub запускать. Не для юзерской машины точно и много нюансов с ней в целом. При всей моей к ней любви, вынужден ею не пользоваться. На работе солярка на спарках, там да, выдерживала отвал диска, но лечился этот отвал сканом в сутки. На отдельной для хранилки машине можно и, скорее, нужно ее использовать, но у меня такой сейчас нет.
Часовой пояс GMT +3, время: 17:16.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.