я вот был просто щаслифф когда у меня /usr на XFS внезапно подох
с тех пор отношусь к нему с опаской

ЗЫ упс есть ;)

Какая версия firefox ? Я после перехода на 3.03 заметил ощутимые тормоза при запуске с раздела на reiser4 с компрессией gzip. Была мысль что фрагментация (source based дистрибутив) после дефрага через cp ничего не изменилось. Раньше ничего подобного не наблюдалось. Возможно винт - в mhdd видны сектора с очень низкой скоростью чтения где-то как раз в начале диска где этот раздел, но они вроде с самой покупки нового диска были..

>Резюме: лучше всего с данной ролью справляются XFS и Reiser4

Странно, почему такое резюме? Мне почему-то показалось, что наиболее стабильные результаты показала jfs (почему-то), причём - стабильно хорошие. Это не критика, скорее вопрос: где я неправ и по каким критериям вы составляли своё резюме?

А обычный reiserfs с параметрами notail,noatime?

Приятная новость. Как раз перешёл на XFS со смертью старого винта.

Вопрос автору, а на ext3 индексация была включена?

http://linux.opennet.ru/tips/info/1345.shtml

У меня /home и /usr на xfs с 2002 года, ныне --- несколько десятков машин. На более слабых машинах, выигрыш в производительности был виден сразу и без вариантов.

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

Результаты не очень интересные. Замерить скорость чтения и не попробовать запись или удаление - это не серьезно. При любых тестах на удаление XFS сливает любой другой FS. К тому же скорость работы XFS сильно упала после 2.6.15, причина непонятна. Когда выбирал себе FS, кандидатов после кучи тестов осталось только двое: Reiser4 (без сжатия!) и ext4dev. После пары падений Reiser4 в течение месяца выбора не осталось. Ext4dev (2.6.24..2.6.27) работает весьма устойчиво, уже где-то месяцев 8. Использую как на станциях, так и в медиацентре и лаптопе. Медиацентр иногда пишет 4 канала HDTV одновременно, проблем не видел.

Особая надежда на 2.6.28, в котором обещали стабилизировать ext4.

>Если Вы попросили p2p предсоздавать файлы перед закачкой то в 3% фрагментации на xfs Вы должны были уложиться

# df -Th .
Ф. система Тип Разм Исп Дост Исп% смонтирована на
/dev/mapper/balvg-downloads
xfs 250G 243G 7,4G 98% /home/balancer/downloads

# xfs_db -r /dev/balvg/downloads -c frag
actual 214907, ideal 70962, fragmentation factor 66.98%

Так что и поболее, чем 40% сейчас :)

Памяти - 1Гб.

>Какая версия firefox ?

3.0.3

>Я после перехода на 3.03 заметил ощутимые тормоза при запуске с раздела на reiser4 с компрессией gzip.

Там у меня ещё SeaMonkey и ldconfig до кучи есть :)

При чём при выполнении второго машина под reiser4 на какое-то время почти вешалась. Винт явно не при чём, текущий /usr под XFS находится на том же месте, где reiser4 был.

>Мне почему-то показалось, что наиболее стабильные результаты показала jfs (почему-то), причём - стабильно хорошие.

Она показала устойчивое второе место, но нигде не была лучше, чем xfs и новая reiser4.

Кроме того, предыдущие тесты показали, что jfs на малых файлах склонна к просто чудовищной фрагментации: http://balancer.ru/2008/06/12/post-1562431.html - на одном уровне с vfat :)

...

А вот на многократной записи больших файлов (имитация multimedia) jfs показала, наоборот, хотя и самую медленную запись, зато минимальную фрагментацию. Видимо, делает перераспределение фрагментов при записи. Правда, не помню, выкладывал я результаты тестов или нет...

А, вот, правда в неоформленном виде: http://www.linux.org.ru/jump-message.jsp?msgid=3079792&cid=3082384

>А обычный reiserfs с параметрами notail,noatime?

В тесте все FS с ro,noatime.

notail - не пробовал. А зачем ReiserFS без tail? :)

>Вопрос автору, а на ext3 индексация была включена?

Нет.

Значит, придётся ещё два теста прогнать тогда. ReiserFS с notail и ext3 с индексацией :) Но попозже.

>Замерить скорость чтения и не попробовать запись или удаление - это не серьезно.

Для /usr важно только чтение.

Другие тесты уже были. И сборка ядра, и многопоточные чтение/запись мелочи, и толстых файлов, и чистая практика, типа emerge...

>При любых тестах на удаление XFS сливает любой другой FS.

Да, и это прекрасно видно, например, тут: http://balancer.ru/tech/forum/2008/06/t62136--Proizvoditel~nost~-fajlovykh-si...

Удаление рабочего каталога после сборки ядра:
ext2: 1,5
ext3: 3,4
ext4dev: 1,9
jfs: 38,1
reiserfs: 5,2
xfs: 197

>А зачем ReiserFS без tail? :)

Работает швыдче, при сохранении всех прочих удобств. Видимо я не умею готовить ext3, потому что всегда какие-то косяки с ним у меня, то файлы потеряются, то тормозит...

Не помню уже где, но видел какуюто сборку l2j от наших перцев, которые не дают исходники. Т.е. LICENSE с GPL внутрь кладут, а исходники не дают. что б с ними сделать?

>Не помню уже где, но видел какуюто сборку l2j от наших перцев, которые не дают исходники. Т.е. LICENSE с GPL внутрь кладут, а исходники не дают. что б с ними сделать?

Собственно, те, кто от нас отпочковались (L2 Rebellion) так и сделали. На вопрос «а как же GPL?» отвечали «а нам пофиг...»

Но они, кажется, в итоге всё равно развалились. Что было вполне ожидаемо с их политикой.

>Работает швыдче, при сохранении всех прочих удобств.

В общем, наряду с dir_index у ext3 поставил себе на заметку: протестировать :)

Нашел. Это l2jgroup.ru - яростные нарушители GPL

Вообще таких не понимаю, за них написали более менее работающий сервер, они его взяли, приписали что-то сбоку и закрыли. Да без основной разработки они бы и шагу не ступили, где же их элементарная человеческая благодарность проекту?

Как юзали ext3, так и бум юзать, а выигрышь в 5 процентов скорости, при возможности потерять данные... Игра не стоит свеч, имхо.

>а выигрышь в 5 процентов скорости

50-70%, см. выше.

Графики наоборот.

Графики надо наоборот делать, должно быть "больше => лучше". Например нужны графики "количество запусков firefox за 1000 секунд" или "количество запусков firefox за 1000 секунд, линейная экстраполяция" (если 0 firefox'ов стартуют за 0 секунд, а 1 firefox за 8,5 с, то за 1000 секунд стартует 117 firefox'ов).

А вообще спасибо.

как и следовало ожидать рейзерFS самые тормознутые

ntfs

>Это l2jgroup.ru - яростные нарушители GPL

Там поле не паханое :)

Вот, судя по FAQ'у по регистрации (документы, паспортные данные, etc/etc), это те, кто с Рибелиона ушли: http://www.l2f.ru/

Естественно, ни слова про GPL :)

xfs_db -r /dev/mapper/debian-Space -c frag
actual 84673, ideal 28441, fragmentation factor 66.41%

ну блин растроили меня. Я думал у меня все в порядке, а тут 60% фрагментации

Уважаемый, на ЛОРе как-то принято охаивать все "тесты".
Вот и у меня вопросы:
0. Конфигурация тестового компьютера. Были ли все тесты выполнены на одной и той же машине? Каким образом осуществлялась "закачка" данных на разделы? Были ли все разделы расположены на одинаковых номерах цилиндров винта? Одно дело, если ext3 на первой тысяче цилиндров... другое - ReiserFS на последней тысяче...
1. Какое использовалось ядро?
2. С какой оптимизацией оно было собрано?
3. Делалось ли sync перед стартом каждого теста?

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

Классно сделали. А еще без JavaScript теперь работает. :)

>А еще без JavaScript теперь работает. :)

Угу. Правда, зато, опять не совсем корректно подсовываются стили девайсам с шириной экрана в 240px :)

>ну блин растроили меня. Я думал у меня все в порядке, а тут 60% фрагментации

ionice -c3 sudo xfs_fsr -t 600 /dev/balvg/downloads

Посмотрим, с какой скоростью у меня будет дефрагментироваться...

>0. Конфигурация тестового компьютера.

P4-2800, 1Гб DDR2, LVM 250+500+640Гб.

>Были ли все тесты выполнены на одной и той же машине?

Да.

>Каким образом осуществлялась "закачка" данных на разделы?

cp -rP /usr/* /mnt/usr3/

>Были ли все разделы расположены на одинаковых номерах цилиндров винта?

Не всегда. Разница в быстродействии тестированных разделов много ниже погрешностей измерения времени.

>Одно дело, если ext3 на первой тысяче цилиндров...

Все разделы - ~20Гб в конце 640Гб тома.

>1. Какое использовалось ядро?

2.6.25-r4 с reiser4-патчами.

>2. С какой оптимизацией оно было собрано?

-O2

>3. Делалось ли sync перед стартом каждого теста?

Об этом сказано в статье. sync - мало, он только кеш записи сбросит. нужно ещё обязательно принудительно кеш вообще сбрасывать.

Выводы
Пока оставляю /usr на UFS2+SU+noatime.
В скором времени /usr/local и /usr/home перенесу на ZFS v.6.

> Теги показывают новости только за последний месяц...

fixed

>> Теги показывают новости только за последний месяц...

> fixed

Изменений не видно :)

> Изменений не видно :)

а сейчас? :-)

>Посмотрим, с какой скоростью у меня будет дефрагментироваться...

За полчаса дефрага (правда, с ionice idle) фрагментация 250-гигового раздела упала с 66.98% до 61.54%. Долгая будет история :)

>> Изменений не видно :)

> а сейчас? :-)

Теперь - отлично! :)

В дополнение ко всему, было бы неплохо еще померить нагрузку на ЦП и память. Может такие замеры уже проводились? Если да, то не поделитесь ли результатами?

>В дополнение ко всему, было бы неплохо еще померить нагрузку на ЦП и память.

Они косвенно входя в sys и user :)

>Может такие замеры уже проводились?

Ловите исходные данные для таблиц: http://balancer.ru/files/0811/Bench.gnumeric

Там есть все данные time.

Но в sys и user ничего интересного, они практически идентичные для всех FS.

Субъективно разница на глаз ощущалась.

«Старый» Reiser4 тормозил неимоверно, просто почти завешивая машину.

Из «чистых» FS больше всего притормаживала ext3. Где-то на её уровне, м.б. чуть меньше - reiserfs.

jfs, xfs и reiser4 («свежая») тормозили меньше всего.

Согласен, при всех преимуществах XFS, есть у нее один очень известный недостаток, при сбое питания в открытых файлах могут быть нули. Ну и с таким подходом мета-данные тоже могут пойти медным тазом

> Удаление рабочего каталога после сборки ядра:
> ext2: 1,5
> ext3: 3,4
> ext4dev: 1,9
> jfs: 38,1
> reiserfs: 5,2
> xfs: 197
а rfs4? я сам специально не замерял - интересно в цифрах...

> «Старый» Reiser4 тормозил неимоверно, просто почти завешивая машину.
а сколько было "старому" разделу с rfs4? мб в свободное время тоже попробую обновить раздел и сравнить "до" и "после"...

>а rfs4?

В том тесте его не было. Я его для интереса в ядро включил несколько позже. А так - шустро он удаляет, на уровне лидеров :)

>а сколько было "старому" разделу с rfs4?

Около 2.5 месяцев. Правда, тут нужно учесть, что я в этот период обновил GCC и в связи с этим пересобрал мир :) Так что /usr очень интенсивно обновлялся.

...

И проблема связана именно с какими-то «накопительными» процессами (в первую очередь подозревается фрагментация), потому что «дефраг мувом» снова сделал раздел шустрым как раньше. Но я от греха переполз на xfs, так как скорость почти та же, а опасности потери данных при падении компа в случае /usr можно не бояться. Да xfs_fsr по ночам можно крутить с низким приоритетом :)

>Хм, нужно поглядеть, как оно будет жить если проект я таскаю домой периодически.

Тогда только Git.

Какбэ спсибо за такие новости, всегда с интересом читаю

My-Suse:~ # df -Th

Filesystem Type Size Used Avail Use% Mounted on

/dev/sda2 xfs 30G 5.4G 24G 19% /

udev tmpfs 2.0G 152K 2.0G 1% /dev

/dev/sda1 ext3 130M 19M 105M 16% /boot

/dev/sda3 xfs 434G 4.8G 430G 2% /home

/dev/sdc1 xfs 466G 417G 50G 90% /home/films

/dev/sdd1 xfs 466G 55G 412G 12% /home/films2

/dev/sdb1 xfs 466G 29G 437G 7% /home/musik_and_images

My-Suse:~ # xfs_db -r /dev/sdc1 -c frag

actual 71195, ideal 1449, fragmentation factor 97.96%

My-Suse:~ # hdparm -tT /dev/sdc1

/dev/sdc1:

Timing cached reads: 4090 MB in 2.00 seconds = 2045.07 MB/sec

Timing buffered disk reads: 240 MB in 3.00 seconds = 79.90 MB/sec

Весь /dev/sdc1 забит торентами... Хард WD5000ABYS. Раньше все было на ext3 - не вернусь.

>hdparm -tT

Он к FS и фрагментации отношения не имеет :) В смысле, что «79.90 MB/sec» - это чистый трансфер с винта. Скопируй файл в гигабайт в /dev/null - и подели объём на время. Получишь реальную скорость.

У меня винт 83Мб/с выдаёт, а скорость иногда до 20Мб/с падает...

> Возможно - вследствие фрагментации.

Лучше заменить на: Возможно это последствия фрагментации.

Тогда уже: «Возможно, это последствия фрагментации.» :)

EXT3 остальное от лукавого