>Хотелось Вам увидеть, что XFS плохая -- Вы это и увидели.

Если только у меня libastral слинковался с libbrain. Повторюсь, я ожидал от xfs только тормозов на удалении. Ибо это, как раз, общеизвестный факт. А тест строился ради jfs и ext4.

Ясно. ext4 будет рулить :)

>Хотелось Вам увидеть, что XFS плохая -- Вы это и увидели.

XFS должна показывать отличную производительность при работе с большими (и очень большими) файлами.

Короче райзер рулит и педалит:)

Перед неачалом каждого теста следовало cделать sync && echo 3 > /proc/sys/vm/drop_caches, время каждого теста замерять вместе с sync. А так имеем очень сильное влияние дискового кеша на результаты, т.е. еще один абсолютно не объективный тест, которых в сети великое множество.

Вообщем, за проделанную работу - похвала, за в корне неверную методику измерений - незачёт.

>А у меня за 6 лет эксплуатации ext3 фрагментированность не превышает 5.6%. У меня пиписька больше. ага?

У меня фрагментация на корневом рабочем (10Gb/70%used) reiserfs-разделе - 0% :)

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

ИБМ давно провела подобные тесты. Сходите на их сайт и найдите. Да, XFS самая лучшая для больших объемов, но по надежности сохранения данных при зависаниях/резетах и по нагрузке на комп jfs лучше всех - меньшая нагрузка, отличная защита от потери данных при очень даже хороших результатах по скорости. В совокупности получается, что для хранения массивов данных она лучше всех.

А то народ потом кричит: "А чтой-то у нас так все тормозит, когда копируем/сидируем и т.д.". Потому и тормозит, что надо не только обращать внимание на скорость единичных операций, а на совокупность факторов.

Старинный вывод: хотите быть уверенными в сохранности, пользуйтесь ext3 или jfs. А лучше ext3 для корневых и jfs для данных.

>У меня фрагментация на корневом рабочем (10Gb/70%used) reiserfs-разделе - 0% :)

на корневом - это и так понятно, что фрагментация около 0-2% колеблется.

И всё-таки слишком малый объем данных использован для тестирования имхо по сравнению с размером ОЗУ. Если бы, скажем, объём ОЗУ была бы 256 Мб, а тестирование производилось бы на объёмах читаемых-записываемых данных 20 Гб, результат был бы интереснее.

>еред неачалом каждого теста следовало cделать sync && echo 3 > /proc/sys/vm/drop_caches

Точно поможет? :) Я, как писал уже, вопрос сброса кеша решал копированием во временный каталог 2Гб мелочёвки. Но это - долго...

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

В общем, готовлю сейчас новую версию теста. Принимаются практические пожелания. Во-первых, в тесте будут vfat, ntfs-3g и, вероятно, reiser4 (занимаюсь его подключением).

Тест будет сугубо практический. Берём из /usr/lib все *.so (1.3Гб) многократно копируем/удаляем в тестовую партицию (имитация обновлений системы) и потом много раз читаем случайные файлы. Вроде как, запуск произвольных программ :)

Т.е. в итоге увидим, какая ФС лучше подходит для /usr

Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

Возможно, если не поломает, реализую параллельное чтение в несколько потоков.

>Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

Думаю есть смысл судить о фрагментации измерением скорости записи/чтения перед началом теста на пустом разделе (фрагментация 0 %) и после искуственной фрагментации - а то эти голые цифры из скрипта вообще мало о чем говорят, при этом не забивать раздел под завязку - это во первых далеко от действительности и во вторых даст не совсем справедливые результаты.

>Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

время с sync при каждом тесте на запись

+ количество занятого места на диске после копирования данных, + результаты reiserfs с notail

yes, ext3 does suck-by-design. Always has. (C) Andrew Morton

> Старинный вывод: хотите быть уверенными в сохранности, пользуйтесь ext3

Историю с порчей данных на ext3 на ядрах 2.6.18 -- 2.6.20 все уже забыли, как
я вижу. Что ж, напомню:

http://kerneltrap.org/node/7518

А вот еще:

http://bugzilla.kernel.org/show_bug.cgi?id=9692

И в довесок:

https://bugzilla.mozilla.org/show_bug.cgi?id=421482#c123

>Перед каждым измерением при наличии в кеше данных, способных повлиять на результат, я делал «сброс кеша» путём копирования на локальный раздел (не тестируемый) 2Гб мелочёвки с удалённого диска.

А сбросить кеш напрямую а не через жо#у не судьба ?


sync
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches

или

sync
echo 3 > /proc/sys/vm/drop_caches

>при этом не забивать раздел под завязку - это во первых далеко от действительности

Ну, у кого как :) 

# df /usr
Файловая система     1K-блоков      Исп  Доступно  Исп% смонтирована на
/dev/sda11            17196972  13024284   4172688  76% /usr

>А сбросить кеш напрямую а не через жо#у не судьба ?

Теперь - судьба :) Раньше я этого метода просто не знал.

> Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

Открыть на запись несколько (~10 -- 20) файлов, и тупо

sleep -- write -- fsync

(примерно это делает текстовый редактор).

На фоне этого запустить копирование нескольких файлов среднего размера
(> объема RAM).

Исп 76% - это нормально :) Еще чисто мое мнение для удобства восприятия сделать один вариант полностью в относительных единицах а за эталон (100%) к которому будут приводится остальные результаты взять любую из тестируемых ФС - какая больше понравится (или не понравится :). Сразу будет видно кто кому сливает :)

Интересно бы посмотреть результаты reiserfs с notail

> jfs лучше всех - меньшая нагрузка,

А кого она волнует?

> отличная защита от потери данных

Не хуже и не лучше, чем у других ФС. За исключением одной назойливой "фичи":
если ФС была нештатно отмонтирована, требуется fsck (journal replay делается
из userspace?).

> при очень даже хороших результатах по скорости.

JFS страдает от фрагментации. Потому с "возрастом" ФС производительность
сильно падает. У свежесозданной ФС скорость записи, измернная по

dd if=/dev/zero of=test.img bs=1M count=4096

была около 65 Mb/сек. Через пол-года использования упала до 8 Mb/sec.
Кроме того, fsync на мелких файлах занимал около минуты. Начал
разбираться -- оказалось, что файлы сильно фрагментированы: у файлов
размера ~10 Mb было по несколько тысяч (!) кусков (extents).
Потому -- ну ее нафиг, тем более что дефрагментатор отсутствует в Природе.

И еще немаловажно - нужно чтобы скорость чтения/записи в начале раздела была примерно равна скорости чтения/записи в конце раздела. (например чтобы раздел занимал не более 10% общего объема диска)

> Так вот, собственно, вопрос о пожеланиях - может, что-то ещё включить?

Угу. Тест файловой системы UFS2 с опцией noatime.
Либо изменить заголовок с "Производительность файловых систем" на "Производительность файловых систем Linux".

а btrfs забыли протестить? :)

Блин, так:

1. Какой IO Schedulers?

2. Какие настройки в ядре файловых систем?

ЗЫ: например, есть ли "Ext3 extended attributes"

> может, что-то ещё включить?

Заполнение раздела под завязку малыми файлами, удаление через одного, заполнение в два раза большими, удаление через два, заполнение большими файлами.

Тестирование выборочного чтения (и других операций) больших файлов.

> Либо изменить заголовок

Вдумчиво читаем URL

JFS умер, все...

Даже в SLES его убрали из официально поддерживаемых.

А вообще тест конечно абсолютно позорно сделан, и "ниочем" (как максимум - "что лучше для плюгавого домашнего компьютера типа хакера васи пупкина) - XFS например на самом деле рвет всех на больших объемах данных (и учитывать необходимо кучу факторов)- простой пример, той же рейзерфс нужно около 15 минут (!!!) чтобы смонтировать большой раздел размером скажем терабайт 15...
Да и ext3 можно оттюнить по самые помидоры- пачка параметров и оптимизаций есть под разые классы задач...

Короче - реально "автор" просто позорится и показывает свою проф. непригодность.

>Короче - реально "автор" просто позорится и показывает свою проф. непригодность.

Ну почему? Если у него все по умолчанию, то это хороший тест для выбора файловой системы домашнему пользователю, который сам ставит линукс и не пересобирает ядро. не оптимизирует и т.п.

ЗЫ: так какой schedules?

>простой пример, той же рейзерфс нужно около 15 минут (!!!) чтобы смонтировать большой раздел размером скажем терабайт 15...

On-demand bitmap loading уже в оф.ядре с версии 2.6.19, вылазь из танка

>Короче - реально "автор" просто позорится и показывает свою проф. непригодность.

Он старается как знает/может, а ты ничего конкретного не предлагаешь

>> народ, а почему xfs так себя плохо показала ?

> Я сам удивился. Не люблю эту ФС,

Может, у вас это взаимно?

В нагрузку (взято с opennet.ru): тестирование ext2, ext3, ext4, reiserfs, reiser4, jfx, xfs, btrfs в iozone, postmark, dbench, maildir и file creation benchmarks на 4-головом Xeon с 4гб памяти и 10k scsi seagate диском 300гб на Adaptec AIC7902 Ultra320:

http://tservice.net.ru/~s0mbre/old/?section=projects&item=fs_contest2

Для Ъ: в postmark рулит btrfs и reiser4, неплохо ext4. iozone random write: ext3/reiser4, read: reiser4, write: reiser4 и btrfs, dbench: ext2 с огромным отрывом, затем ext3 и ext4, file creation: ext2.

>JFS умер, все...

JFS оффициально не развивается (да и не поддерживается) уже несколько лет в ядре. Т.е. только багрепорты по нему фиксятся, но настолько медленно, что проще переползти на xfs.

какая самая надежная фс?

Смонтированная с параметром ro

>ЗЫ: так какой schedules?

cfq

В общем, готовы две серии данных по новому тесту, уже сугубо практическому - параллельное случайное чтение *.so из /usr/lib. Результаты интересные, особенно в области фрагментирования.

Теперь стоит вопрос визуализации. (Пока вожусь - глядишь, и третья серия подоспеет).

В доке по gnuplot не нашёл подходящего формата диаграмм. Чтобы для каждой ФС по N измерениями построить столбик диаграммы с минимальным, средним и максимальным значением. В MS Excel и OOo Calc таких диаграмм не нашёл тоже :)

В общем, нужно как-то это визуализировать теперь...

>А вообще тест конечно абсолютно позорно сделан, и "ниочем"

Ещё раз рекомендую прочитать, о чём же тест. Там всё подробно расписано. Настолько, что твои реплики выдают пока или неумение/нежелание читать, или неспособность к умозаключениям. Глобальные задачи, которые ты почему-то тут видишь, при тесте не ставились. В общем, у Вас галлюцинации...

Самая надежная ФС — это iso9660.

$SUBJ.

> Смонтированная с параметром ro

Не факт. Дело в том, что журналируемые ФС делают journal replay, несмотря
на ro. Что вполне может привести к потере данных (например, если
половинку с RAID1 массива подмонтировать).

А говорили, что reiser быстрее ext2...

>А говорили, что reiser быстрее ext2...

правильно говорили

Всё конечно хорошо, НО! размонтировался ли после каждой операции раздел дабы сбросить файловый кеш?

Какой планировщик?

перечитай еще раз тред

UFS, ZFS планируется?

Также интересны многопоточные операции, дабы посмотреть как время поиска снижает скорость.

вкурил.

Абсолютно согласен, я аж удивился, как все тут с серьезными лицами обсуждают результаты этого "теста". 2ГБ - это очень странный объем для такого тестирования. У меня в ноуте трехлетней давности - оперативной памяти 1ГБ. Автор, что Вы измеряли?

>А говорили, что reiser быстрее ext2...

Во втором тесте он на случайном чтении *.so из /usr выполняет всё за 71,2-71,3 сек. против 74,5-75,6 сек. у ext2 (три измерения, точнее, третье заканчивается, остались vfat и xfs). В общем, паритет. Для сравнения, такого же порядка величины у jfs, xfs и reiserfs (от 62,6 до 76,8 сек.). А вот reiser4 выполняет тест за 54,9-55,0сек; ntfs-3g за 125,4-125,6сек.

Интересны результаты по уровню фрагментации:

xfs: 0,02-0,03
ntfs-3g: 0,85-1,85
reiser4: 2,18-2,51
ext2: 4,3-5,9
reiserfs: 6,9-8,9
ext3: 14,1-21,1
jfs: 34,0-37,2
vfat: 39,2-40

Фрагментация для ext4dev, как писал ранее, не определяется.

...

Как бы б результаты эти визуализовать... Разброс значений явно не позволяет задействовать простые диаграммы, нужно с тремя значениями... Хотя, конечно, можно их и ручками вписать, с другой стороны. Их всего-то три :)