Сравнение файловых систем

>у меня нет на Debian'е /sys/block/sdb/queue/scheduler, путь есть, а >файла scheduler нет.
>А в ядре 2.6.9 с kernel.org нет IOShedulers (в пункте Block Devices).
может быть вполне.
обновите ядро

Не падает, потому что не стоит. А когда стояла - то стояла по году, собственно я в ней очень мало работал, только если по Эксесу какие задания были, или по Дельфи... Ну, и в "Они" поиграть, а то под cedeg'ой не шла... Кста, мож кто знает, как ее пустить под linux?

#ram32

<Для всех, кто продолжает уверять, что Reiser'ы - это де круто. Методика тестов полностью описана - повторите - выложите сюда результаты - мы обсудим. А то "у меня Reiser4 быстрее ext3 в пять раз" и "бла-бла-бла" - цифры и факты в студию!

Хватит, беспредметной болтовни! >

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

я однажды потерял все данные на рейзере, больше не хочу его юзать. втопку. ext3 форева :)

cat /sys/block/hda/queue/scheduler
покажет какой scheduler активен в данный момент

а
echo cfq > /sys/block/hda/queue/scheduler
поменяет текущий scheduler на cfq прямо на лету

Сам ты ослик.

Да, я специально пересобрал ядро с отключенным DMA, чтобы стало легче жить.

Сначала читай все посты, потов вякай.

Спасибо.

> смешно....рейзер..медленный.... а вот попробуйте полазить в /usr/portage в ext3 и в reiser....результат на лицо..... ext3 в топку! P.S. emerge metadata на reiser пулей... что не скажешь о ext3

А, ну всё ясно. Райзер - для пионеров-гентушников

Похоже что ты прав. Прямо сейчас копирую эти же фильмы, причём загружено много всего (в первый раз копировал из-под консоли, и в это время пытался пускать KDE). Скорость - 20-30мб/с (source раздел в конце первого диска)

> Берем памяти 64 и ntfs занимает первое место.

По чему она занимает первое место, малыш? По поиску файла в каталоге, полном говна? Ну да. А что она ещё может делать быстрее, чем FAT32? Ты просто пердишь, а я их сам сравнивал га P4-1,7 с 256 Мб RAM. NTFS стабильно сливала практически везде. Или ты, дурашка, думал, что наличие журнала её ускорит? :)

> а что теперь для файлопомойки нужен двухголовый AMD 64?

Разумеется. Настоящие поцаны тем и отличаются от людей с мозгами, что неспособны придумать деньгам лучшее применение. И повсюду хвастаются своей непроходимой тупостью :)

> Кстати, тоже самое с licq было у меня на reiser3 уже раза два. Подозреваю, что дело тут не в ФС.

Какая версия licq?

+1

У меня дома на двух компах reiserfs + (1) 2.6.8 и (2) 2.6.15. Одна стабильная машина, а вторая комп с разогнанным процом(атлон 2200) и памятью. Часто тестирую всякие на ней всякие mm патчи и тому подобные не стабильные вещи, с соответственно, частыми ресетами. И проблем серьезных с файловой системой не было вобще, только один пришлой ребуилд-три делать.

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

Конечно привычнее фс которые не нагружают процессор. Но если за счет этого достигается большой рост скорости работы с диском, это не кажется чрезмерной платой. Очень часто именно процессор - неиспользуемый ресурс.

> Только идиоты ставят Gentoo на сервер, и вдвойне идиоты

> хранят данные на Reiser-е.

Боже, у меня появился близнец? Не знаю, кто ты - анонимус, но я пью пиво за твое здоровье :) Есть ещё здравомыслящие люди!!!

> у меня reiser3 стоял на 'сервачке' старом, который последние пару месяцев чуть ли не по 3 раза в день перезагружался из-за блока питания

Понимаете ли, старые сервачки - они обычно того, стоят на подхвате, особо не загружены - ну используются они как файлсервер или DNS/DHCP - так оно же практически не пишет. А речь шла именно о вероятности сбоя в момента активной записи.

> Да, я специально пересобрал ядро с отключенным DMA

Зверь мужик! :-) DMA придумали как раз чтобы освободить процессор для более важных задач - то есть эта штука нужна для того, чтобы сказать контроллеру "данные вон там, теперь иди пиши, о результатах доложишь". А без этого любая ФС в процессе записи стремительно пригибает систему до нефиг нафиг.

Ой, а я от умных людей (Irsi) слышал, что NTFS многопоточная....

PS: Сам два года пользуюсь Reiser3 - никаких нариканий, ни единого сбоя, проблем со скоростью доступа к данным никогда небыло.
PPS: Советую всем присмотреться к версиям используемых файловых систем + используемым ядрам (патченными перепатченными).

ему небось RT нужон

> Конечно привычнее фс которые не нагружают процессор. Но если за счет этого достигается большой рост скорости работы с диском, это не кажется чрезмерной платой. Очень часто именно процессор - неиспользуемый ресурс.

Но для ноутбуков райзер противопоказан. По той же причине :)

>Зверь мужик! :-) DMA придумали как раз чтобы освободить процессор для более важных задач - то есть эта штука нужна для того, чтобы сказать контроллеру "данные вон там, теперь иди пиши, о результатах доложишь". А без этого любая ФС в процессе записи стремительно пригибает систему до нефиг нафиг.

Гы сына лол. Вообще-то фраза была сказана с издевательским акцентом )

Естественно DMA включено :) И по-моему, я уже разобрался (перечитай посты чуть повыше)

И этот туда же :D

> Ой, а я от умных людей (Irsi) слышал, что NTFS многопоточная....

Многопоточность, малыш, это не самоцель. Это средство, позволяющее добиться чего-то. Так вот, покажи мне на простом тесте, как скорость ntfs выигрывает оттого, что в ней есть многопоточность. Опиши условия эксперимерта, а я потом проверю у себя, договорились?

<Боже, у меня появился близнец? Не знаю, кто ты - анонимус, но я пью пиво за твое здоровье :) Есть ещё здравомыслящие люди!!!>

Анонимное раздвоение личности ? Тогда у лора приоритет на открытие. Всем выпивки :>

Не пей log1n за анонимусов, помнишь трагедию аленушки ;-)

Кроме того, здравомыслие часто противоречит опыту, так как в действительности все совсем иначе, чем на самом деле (Мысль увы не моя)!!!

Просто протестируй сам, а если неохота тратить время, то просто возьми калькулятор и проведи численный эксперемент. Посчитай скажем 70 % от 2400 Мгц, и убедись, что описанный в новости тест не может противоречить тем результатам, которые описывают другие люди на более мощных компьютерах.

<Но для ноутбуков райзер противопоказан. По той же причине :)>

Ну, я же не религию проповедую :-)

А чё, райзер действительно монтируется десятки секунд???? Мама моя! А я ещё подумывал на него переходить...

Это уже интереснее. Сразу договоримся что речь только о десктопе.

>Как и про то, что всякие "сжатия" и прочее тебе все равно здесь не помогут - когда любое изменение в данных будет порождает изменение в размерах блоков (мы про принципы работы алгоритмов сжатия надеюсь слышали?) и их переупорядочивание. После трех операций у тебя будет там на диске ТАКАЯ котовасия, что на одних сиках головки винта ы потеряешь в четыре раза больше времени. Если же оставлять всякие "резервы" в записываемых блоках под возможный рост энтропии в данных и последующее увеличение объема сжатых данных - то опять же - ты ничего не выиграл на объемах реального чтения с диска.

Почти всегда файл либо полностью переписывается или дописывается в конец. Внимание вопрос: что запишется быстрее файл в 120mb или тотже файл сжимаемые на лету (в памяти) 60mb? Если дописывать - тоже самое, в обоих случаях меняется только последний сектор.

>И напоследок - если у тебя идет активная работа с /tmp - то следовало просто добавить памяти, увеличить свап и примонтировать /tmp как tmpfs - опять же, это будет раза в два эффективнее, чем любые "компрессии" и прочее, ибо оно не входит на уровень блочных устройств, контроллеров и прочего, а живет целиком в VFS и свапе, что исключает двойную запись (в журнал и на саму фс).

Да уже второй год так и использую, а то помер бы в ожиданиях. Но сохранение/открытие файлов на ext3 не радует :(

>В общем, иди учи матчасть, прежде чем заявлять про "лучше". Кстати о птичках - когда накладываешь тяжелый эффект на большую картинку, "сжатия" и прочии "оптимизации" замедлят работу отнюдь не на 20%. Для любителей поэксперементировать - возьмите кваку вторую, поставьте ее под виндой на NTFS, и запустите. А потом установите флажок "сжатие" на всех ее файлах и снова запустите. Можете также попробовать создать файл из одних нулей мегабайт на 30, установить на нем флажок сжатия, и потом перезаписать его какими-нибудь хорошо пожатыми (или просто хорошо рандомными) данными.

У кваки файлы изначально сжаты. Повторное сжатие действительно может ухудшить скорость. Сжатие тоже нужно применять с умом. И насколько я знаю в рейзере планировался список расширений файлов не подлежащих сжатию, типа *.rar *.bz2 и т.д. Второй тест полный маразм, но в теории даже он должен быть быстрее - ненужно освобождать тучу секторов предыдущего файла. Проверю.

Я еще под nt4 ставил рейды и сжатие на ntfs. На больших файлах от corel draw и photoshop оно дает реально большой прирост на сохранении/открытии файлов. Это реальный опыт, который и посей день приносит пользу. Не верите - проверьте.

а я пользовал как рейзер так и ХФС - разниц&#1110; особой замечено не было. %) Счас рейзер 4, тормозов нима. Да, оно грузит проц, но не тормозит.

Провел замеры:

Три файла забиты нулями, каждый по 700mb. Один из них не сжат. У сжатых физический размер 512 байт.

Три файла по 700mb содержащих фильм. Один из них тоже не сжат. Физический размер сжатых меньше на 200 kb, то есть повторному сжатию они почти не поддаются.

1. Замена нулевого не сжатого сжатым фильмом 43с. 2. Замена нулевого сжатого сжатым фильмом 57с. 3. Замена нулевого сжатого не сжатым фильмом 45с.

В первом случае у нас происходит распаковка фильма. В третьем случае происходит упаковка. А второй случай скорее всего представляет собой распаковку и последующею упаковку, то есть сама реализация файловой системы не совсем верна, можно было бы просто физически скопировать уже сжатые сектора. Но это оставим на совести инженеров M$, который проектировали NTFS.

Копирование нулевого сжатого файла происходила со скоростью 100mb/s и уперлось в скорость проца, что еще раз подтверждает догадку о пересжатии. Но в любом случае цифра впечатляет. Такого прироста от сжатия на реальных файлах конечно не будет, но в 2-3 скорость повышается, если в проц не упрется.

P.S. куча копий для минимизации влияния кэша на результат.

Где то год назад тестировал xfs, jfs, ext2, ext3, reiser3 на вот таком железе: athlon 1100, 512MB ram, 80GB IDE (7200RPM, 8MB cache). 2.6 ядро с grsec. патчами. selinux не использовался.

Создавалась fs, запускалось много раз с разными настройками bonnie, и что то есче (уже не помню), потом удалясь fs, на том же месте создавалась другая.... Где то год назад на opennet.ru пробегал скриптик который это делает.

В итоге на том железе получилось так: 1. jfs 2. xfs/reiser 3. ext2/ext3

Ну я и поставил там всё что можно на jfs. А этот jfs оказалось очень плохо относится к тому, что питание выключают... рубильником на щитке. Незнаю как сейчас ситуация, но тогда чтобы оживить раздел приходилось втыкать винт в другую тачку и там всё чинить. Читилось исправно, но самопочинка после выключения рубильником никак не работала.

Тогда поставил reiser на / и xfs на /home. И reiser и xfs проработали успешно год и никаких проблем с ними небыло. Выключение питания рубильником бывает раз в неделю-две и до сих пор. В /home находится файлопомойка с преимущественно большими файлами к которым по сети обращается 10-20 юзверей.

Узким местом оказалось железо. Винт не выдержал издевательсв и мрачно умер. С reiser удалось восстановить всё, с xfs ничего. От xfs`овских утилит было очень много ругани на кривой журнал и даже не удалось заставить монтироваться раздел.

Сейчас всё работает на ext3 с data=journal, ну и UPS есчё поставил.3 месяца полёт нормальный.

> Ну я и поставил там всё что можно на jfs. А этот jfs оказалось очень плохо относится к тому, что питание выключают... рубильником на щитке.

Еще один пионер.

> Винт не выдержал издевательсв и мрачно умер.

Винт не выдержал присутствия безмозглого админа, который сразу не поставил UPS.

>Что мне не нравится в ext2 (не знаю как в ext3), так это непредсказуемость после перезагрузки - случайной или специальной.

ext2 уже лет 5 нигде не используется, а в ext3 такой проблемы нет

>А что , самому протестировать слабо, или много умения надо ?

юзал reiser3 довольно долго, никакой суперпупер производительности не обнаружил, из-за проблем с порчей fs ушел обратно на ext3

На сколько я помню о коллизиях подумали в reiser4. Там даже был такой тестовый хеш, который на любую строку выдавал одинаковое значение хеша :) Коллизия в reiser4 ведет просто к потере производительности, так как приходится директорные записи сравнивать строка-к-строке начиная от места коллизии. Так что потеря производительности тоже не большая если коллизнутых записей мало.

Про reiser3 не помню, чтото мне подсказывает что там это может привести к неприятностям.

> Внимание вопрос: что запишется быстрее файл в 120mb
> или тотже файл сжимаемые на лету (в памяти) 60mb?

Не люблю пустословие - давайте предоставим слово цифрам и тестам?

$ dd if=/dev/urandom of=xx bs=`expr 1024 "*" 1024` count=120
120+0 records in
120+0 records out
$ time gzip -c <xx >/dev/null 
real    0m11.500s
user    0m10.885s
sys     0m0.372s
$ gzip -c <xx >ee        
$ ls -l ??
-rw-rw-r--  1 dalth dalth 125849035 Мар  8 14:13 ee
-rw-rw-r--  1 dalth dalth 125829120 Мар  8 14:12 xx

Итак, только на пожатие данных у нас ушло 11 секунд. Стоит
отметить, что скорость передачи записи на ФС на этой машинке
в среднем составляет 20-25 мегабайт в секунду. И где выигрыш -
-нам ведь 11 секунд жать + 3 секунды записи против 6 секунд
записи? Ладно, спишем все на плохосжимаемые данные. Возьмем
структуру данных попорядочней?

$ rm ee xx
$ dd if=/opt/dist/fc2/fc2cd1.iso of=xx bs=`expr 1024 "*" 1024` count=120
120+0 records in
120+0 records out
$ time gzip -c <xx >/dev/null 
real    0m11.111s
user    0m10.553s
sys     0m0.324s

Мля!!! Опять 11 секунд и трехкартный проигрыш! Но может быть
у нас на ISO-шке лежали уже пожатые данные? Точно! Там же
дистрибутив и все типа уже пожато! Проверим?

$ gzip -c <xx >ee
real    0m13.153s
user    0m11.357s
sys     0m0.784s
$ ls -l ??
-rw-rw-r--  1 dalth dalth  89422369 Мар  8 14:17 ee
-rw-rw-r--  1 dalth dalth 125829120 Мар  8 14:16 xx

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

# dd if=/dev/hda1 of=xx  bs=`expr 1024 "*" 1024` count=120
120+0 records in
120+0 records out
# time gzip -c <xx >/dev/null
real    0m12.917s
user    0m12.341s
sys     0m0.280s
# gzip -c <xx >ee       
# ls -l ??
-rw-rw-r--  1 dalth dalth  63786021 Мар  8 14:24 ee
-rw-rw-r--  1 dalth dalth 125829120 Мар  8 14:22 xx

Совсем грустная картинка - нормальные данные, нормально пакующиеся
(коэффициент сжатия 2 - это естественный показатель), но упаковка
опять - таки заняла почти 13 секунд. Очень, очень, ОЧЕНЬ плохо.

На всех тестах со сжатием цифры показывают, что попытка сжать
данные для уменьшения I/O привела не к повышению производительности
за счет двукратного уменьшения объема записываемых данных, а напротви,
привела к двукратному падению производительности, причем система
была вынуждена отдать все ресурсы на обслуживание процесса записи,
то есть если бы у меня параллельно какая-нибудь орфография проверялась
в большом документе, картина была бы еще хуже.

Это цифры - они врать не способны.

Народ, а как дефрагментировать эти все fs?

У меня стоит XFS, но я кидал на нее параллельно и мелкие и больишие файлы. Явно разброс не деский, хотя она мало подвергается дефрагментации. Это нужно в больинстве случаев для слива dv avi файлов. Что бы они не разлетались на кусочки по диску.

Копирование с диска на диск просьба не предлагать. Уж больно огромен массив /home и малы /tmp итд. Просто напросто не перекинуть 200 Gb с /home на /tmp :))))

Есть идеи?

> С reiser удалось восстановить всё, с xfs ничего. От xfs`овских утилит >было очень много ругани на кривой журнал и даже не удалось заставить >монтироваться раздел.

Опять-таки, не могу подтвердить -- ни с теоретических, ни с практических позиций. Внутренняя структура xfs такова, что данные хранятся... ну скажем для простоты так, в обособленных мини-разделах, да ещё и "размазаными" по диску. Поэтому вероятность того, что штатными утилитами не удастся "вытащиь" данные -- почти невероятна, при полном сканировании диска -- что-то, да всегда спасётся. Конечно, при этом надо соблюдать инструкци, работать на размонтированом разделе, не кидаться сразу применять xfs_repair при сообщениях о не найденном суперблоке: сперва хорошо бы проверить, не "скорректировала" ли слегка win-98, буде таковая присутствует на компьютере, содержание таблицы разделов (расследование всех случаев потери суперблока xfs, с которыми я сталкивался у нас в институте, *всегда* приводило к рядом стоящей w98).

Другой вопрос, что в тяжёлых случаях, имена (! только имена, содержание нормальное :) восстановленых файлов будут представлять собой мешанину цифр -- но это проблема не xfs как таковой, её структура позволяет вытащить всю информацию -- это проблема конкретной реализации утилит восстановления.

> Ой, а я от умных людей (Irsi) слышал, что NTFS многопоточная....

а это путаница в терминологии. под потоками M$ разумеет то, что разработчики называют расширенными атрибутами (EA) и что ранее вошло в стандарты и все учебники именно под названием EA. Взять понятие Р.А. и обобщить его не только для случая хранения ограниченного набора дополнительных данных и метаинформации, но и приспособить для хранения данных неограниченного объёма, фактически, как альтернативный файл связанный с первичным именем -- забавно, но к быстродействию отношения не имеет. Самое главное -- вопрос "зачем", разработчикам в голову не приходил, наверное: проблем огребли порядочно, выгоды -- непропорционально мало. Ну а если считать, что в "потоках" -- сиречь Р.А., нормальные люди хранят ограниченый набор метаданных -- то *все* современные Ф.С., кроме что, разве 4-го райзера -- "многопоточны". /GL

> Народ, а как дефрагментировать эти все fs?

>У меня стоит XFS, но я кидал на нее параллельно и мелкие и больишие >файлы.

неоднократно обсуждалось. xfs -- представитель экстентных, не использующих идею кластеризации, ф.с. Выигрыш от дефрагментации -- проценты. В нормальных реализациях ф.с. такого рода, частичная дефргаментация -- точнее, оптимизация размещения, постоянно проводится драйвером файловой системы -- в периоды бездействия (idle) ОС, незаметно для пользователя. Вот как дела обстоят в линуксовой реализации -- не знаю, но подозреваю, что если и не блестяще, то достаточно неплохо: за несколько лет активной работы на хорошо заполненых xfs разделах, заметной деградации производительности, не отмечается. /GL

у reiser4 есть on-line repacker, он же дефрагментатор, он же ресайзер если нужно. Но вроде он небеспланый был.

offline дефрагментатора нету, допишите кто нибудь :)

> $ gzip

Еще бы bzip2 использовал. Вот с этим http://www.oberhumer.com/opensource/lzo/ потести.

Речь шла о тесте, о скорости, а не о чудесах. И к тому же о рейзер4 а не о рейзер3.

>Не пей log1n за анонимусов, помнишь трагедию аленушки ;-)

Не с Аленушкой как раз все нормально было, а вот с братцем Иванушкой... ;)

>Внимание вопрос: что запишется быстрее файл в 120mb или тотже файл сжимаемые на лету (в памяти) 60mb?

А можно пример такого файла, пожалуйста? Обычно файлы такого размера (архивы, музыка, картинки, кино) уже идут со сжатием.

>Про reiser3 не помню, чтото мне подсказывает что там это может привести к неприятностям.

Вобщем вывод: чтобы не было проблем use reiser4 и то после того как его доработают, отладят окончательно и в ядро впихнут? Потому как на reiser3 у меня данные портились даже просто так, при копировании, а не при выключении питания.

при копировании?... Это странно, тебе надо по квартире с дозиметром походить, вдруг чтото интересное найдешь.

Ну той квартиры нет у меня уже ;) Все может быть, но такая же ерунда была еще у 2-3 друзей (и тут на ЛОР-е неоднократно обсуждались подобные грабли). После чего мы все дружно вернулись на ext3. Железо было самое разное: матери VIA, Intel, nForce для Athlon, Toshiba notebook.

Вот я теперь и пытаюсь выяснить: есть ли преимущества при возврате к рейзер, и как дела с надежностью обстоят. Почему, например, Линус не хочет ее в ядро включать?

Похожие симптомы были у одних парней из европы, вроде они сказали что они в рентненовской рабаратории работали или в одном здании с ней :) Грин помнит детали, потому как он ими занимался.

> Почему, например, Линус не хочет ее в ядро включать?

Угу, а в fs/reiserfs наверное ext3 замаскированная...

> Это странно, тебе надо по квартире с дозиметром походить, вдруг чтото интересное найдешь.

С рейзиметром походить и фрю^W чертей изгнать из системника. :)

>На всех тестах со сжатием цифры показывают, что попытка сжать данные для уменьшения I/O привела не к повышению производительности за счет двукратного уменьшения объема записываемых данных, а напротви, привела к двукратному падению производительности, причем система была вынуждена отдать все ресурсы на обслуживание процесса записи, то есть если бы у меня параллельно какая-нибудь орфография проверялась в большом документе, картина была бы еще хуже.

>Это цифры - они врать не способны.

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

Для файла 700mb (сделан из начала hda1):

time lzopack test.tmp test1.lzo

lzopack: compressed 734003200 into 519447542 bytes

real 0m55.237s user 0m18.105s sys 0m6.048s

time cp test.tmp test2.tmp

real 1m4.631s user 0m0.048s sys 0m9.005s

Выигрыш сжатия есть, но он минимален, скорее всего во время записи/чтения компрессия не происходит, так как видна не постоянная загрузка i/o, но и в проц не упирается.

Теперь посмотрим ситуацию при чтении файла:

time lzopack -d test1.lzo /dev/null

lzopack: decompressed 519447542 into 734003200 bytes

real 0m15.976s user 0m2.028s sys 0m1.956s

time cp test.tmp /dev/null

real 0m20.624s user 0m0.036s sys 0m2.268s

Опять победа за сжатием. При правильной организации буферов i/o на уровне файловой системы с учетом компрессии эффективность будет гораздо выше.

Между тестами запускался hdparm -t /dev/hda для минимизации влияния кэша.