Испытание для JFS

Есдинственное что не понравилось мне - на jfs, по сравнению с ext3, например, при операциях с метаданными количество io/s больше в десятки раз. Для ноута - я решил что ни за что.

>на xfs сталкивался с другим косяком -- открытые на момент >ресета/выключения файлы забивались нулями. такое было и с .history, и с >рабочими файлами. было ОЧЕНЬ неприятно играть в игру "угадай, какой >файл мы испортили сегодня".

>последние года 3-4 на ext3 -- живет отлично. на xfs остались только >очень старые архивы с музыкой/фильмами в r/o.

Аналогично + такая же ерунда была и рейзером. В результате тоже ушел на ext3 после серии тестов ( RAID-5 на 6 sata disk . used bonnie) Оказалось в моем по крайней мере случае ext3 оптимальной по скорости за искючением удуления большого кол-ва файлов. Ну и надежность.

>гоняю на одной машинке JFS, так вот что получается: при потере питания, после перезагрузки jfs не монтируется до тех пор, пока не сделаешь ей fsck. Причём со 100% вероятностью

Поставь "0 2" в /etc/fstab - перед монтированием произойдёт автоматический fsck (пару секунд).

Тоже поделюсь своим мнением, раз на раз вобще не приходиться в случаях с ФС. Сам использую под linux reiserfs уже более 3 лет на куче серверов. По сравнению с JFS или XFS куда как более надежная. EXT3 более тормозная да и убивалась наглухо тоже несколько раз. А вобще круче FFS из BSD :-) но тоже смотря под что.

я несколько лет назад пробовал jfs, осталось впечатление добротного продукта.

А уж по сравнению с райзером, который репортит нулевое кол-во инодов:

# df -i /                                                   [15:28]
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1                  0       0       0    -  /

# mount | grep sda1                                         [15:28]
/dev/sda1 on / type reiserfs (rw,noatime,attrs)

>> Скажите лучше что надо сделать чтобы оно не тормозило?

> Сменить то, что у тебя стоит на ReiserFS.

Главная проблема (и достоинство) Райзера в том, что почти вся FS внутри Giant Lock.

>Линакса

К логопеду, быдло!

> Даже когда посыпались бэдблоки на двух хардах

Э-э-э../ Мнэ-э-э... Харды антикварные, 80-х годов выпуска с автографом Столлмана, сделанным тогда же?

> Правда fsck работает 9 часов, это здорово бесит.

9 часов в сутки? А перерыв на обед?

> ЗЫ вообще reiser шустрее бегает когда elevator=as

"AS" - это который самый тормозной? Чудные дела творятся в мире...

> Э-э-э../ Мнэ-э-э... Харды антикварные, 80-х годов выпуска с автографом Столлмана, сделанным тогда же?

Такие винты тебя и твоих внуков переживут, сынок.

> Такие винты тебя и твоих внуков переживут, сынок.

Угу. Пронесут понятие "badblock" через века.

> А уж по сравнению с райзером, который репортит нулевое кол-во инодов:

Ужасно! То, что reiserfs избавлена от очень милой проблемы недо-ФС - нехватки инодов, - это кошмарный недостаток, я считаю.

> "AS" - это который самый тормозной? Чудные дела творятся в мире..

as следует использовать когда самую большую нагрузку на процессор дает IO, а reiserfs как раз и грузит систему больше других, благодаря чему и работает шустрее на файлопомойках.

Anticipatory (упреждающий конвейер) вводит управляемую задержку перед обработкой операции в попытке объединить и/или переупорядочить запросы, улучшая смежность и уменьшая количество операций перемещения по диску. Этот алгоритм предназначен для оптимизации систем с небольшой или медленной дисковой подсистемой. Одним из побочных эффектов этого планировщика может оказаться увеличенная задержка ввода/вывода. Из дизайна планировщика следует, что он лучше всего подойдет для клиентских систем и рабочих станций, для которых интерактивность работы имеет приоритет над задержками ввода/вывода. // http://www.opennet.ru/base/sys/io_scheduler_linux.txt.html

> ну это делается 1 раз при старте системы. Вы что, каждый день компьютер запускаете?

Класс!

> 9 часов в сутки? А перерыв на обед?

см. предыдущее сообщение.

Отличная файловая система.. Нереканий не имеется..

Поделюсь опытом: использую xfs в режиме "readonly" (3.5T, 6*750G, SATA RAID5) на раздаче небольших (1М-5M) файлах с конкурентностью в ~200-300 коннектов - полет нормальный.

Я тут провёл собственное исследование, получил следующие результаты:
Раздел	Размер	ФС	Запись 1000Мб	Чтение 1000Мб	500/500	20000	Used 1K-blocks	Удаление
/dev/sdb1	6000	Ext2	29.9	41.7	17.038	5.349	17408	18.311
/dev/sdb1	6000	Ext3	25.8	41.4 	20.054	1.333	150812	23.484
/dev/sdb1	4096	FAT16	30.3	41.9 	79.912	73.730	32640	11.269
/dev/sdb1	6000	FAT32	30.9	41.2	49.244	73.722	8644	8.897
/dev/sdb1	6000	NTFS	43.2	39.6	177.521	14.559	355000	110.083
/dev/sdb1	6000	ReiserFS	25.0	39.9	13.331	1.148	58848	13.241
/dev/sdb1	6000	JFS	30.9	42.2	78.592	4.129	153392	182.668
/dev/sdb1	6000	XFS	14.2	41.0	Не завершено	125.949	744036	1588.065
/dev/sdb1	6000	<нет>	41.6	41.4	-	-	-	-
/dev/sdb1	2048	HFS	41.9	42.1	234.927	10.742	146592	40.736
Короче, если мне нужно хранить фильмы и музыку я просто возьму фат, ибо он на этих задачах быстр.
Подробности тут http://legolegs.narod.ru/admin/fsbenchmark.odt

А можно у вас узнать, как это получилось, что запись на reiserfs получилась быстрее, чем чтение? Причем на 60%... Вы вообще sync делали?

Где?

ReiserFS 25.0 39.9

Вы наверно имеете ввиду NTFS. Он через fuse работает, так что хрен его знает что с ним. sync я делал, см листинг в odt-шнике.

Для того, чтобы резет не портил данные неплохо было бы с кешами аппаратными разобраться. 3варь с батарейкой, райд 5 аппаратный и бесперебойник уберегут от глюков железа и питания. Без этого вас никакая фс ваабще не спасёт. А вот от глюков и висов софта, в том числе естественно ядра, вас уже должна спасать фс с журналом. Сам давно уже, примерно с 98 года, работаю на станциях с похожей конфигурацией... Ну просто стабильность железа мне ОЧЕНЬ критична... Очень долго сидел на ext2, и, да сел на рейзер когда он только появился. Специфика у меня такая, что ядро я достаточно часто вешаю :) Так что восстанавливаться после краша мне нада часто. И вот ext2 задрала медлительностью подъёма... А рейзер после двух крашей привёл систему в нерабочее состояние. В открытых на момент жосткого виса файлах оказывался бред сумашедшего. Восстанавливался с лент и решил что ЭТО не юзабельно :) Переехал на ext3 и нарвался на тот самый жуткий глюк :) Очень редкий, чёто у с адресацией было на больших разделах.... Короче всё это время я отменно просвещался в теории, ибо реально напрягало всё это. Вернулся на рейзер, он к тому времени научился ordered data mode и глюки с бредом пропали. Но. У него проблемы есть реально. Попробуйте создать раздел и забить его под завязку. Поудалять там и посоздавать файлики. И вы познаете фрагментацию :) Тормозить будет нечеловечески. Причём раза два у меня упало всё на ровном месте и так и не починилось (unknown uniqueness). Теперь там xfs. Но верно высказался товарищь выше. Таких мелких и непонятных глюков как на xfs я нигде больше не видел :) Хотя она очень гибко настраивается под производительность. Сейчас прочёл статью и попробую jfs. Потом раскажу :) Нет блин идеала :)

Уважаемый анонимус, не могли бы вы прокомментировать полный провал XFS в моём тесте? Я теряюсь в догадках.

Интересно провести тестирование разных фс с многопоточном режиме. Т.е. читать и писать в несколько десятков или сотен потоков (как в "боевых" условиях на серверах). Да и размер тестируемого раздела в 6G, равно как и винчестер в 40G далеки от реалий.

>Где?

>ReiserFS 25.0 39.9

>Вы наверно имеете ввиду NTFS. Он через fuse работает, так что хрен его знает что с ним. sync я делал, см листинг в odt-шнике.

Сорри, Это я ошибся, подумав, что там указанны секунды, а не скорость...

>У него проблемы есть реально. Попробуйте создать раздел и забить его под завязку. Поудалять там и посоздавать файлики. И вы познаете фрагментацию :)

Если мне не изменяет память, в состав reiserfsprogs входит штатный дефрагментатор. ;)

Задержка при монтировании reiserfs.v3 имела место, но давно была пофиксена, еще в ядре 2.6.19.