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

Ну-ну. Если я в гимпе работаю с форматом A2 и его свопом в несколько гигов, мне многозадачность что-то не помогает. Понятно, что xmms работает. Но он и все прочее возьмет 10% процессорного времени. Когда происходит обращение к свопу проц загружен на 20%, остальные 80% в idle. Я бы предпочел загрузку проца на 40-80% и скорость работы файловой системы в 2-4 раза выше. Я специально написал, что десктоп. На сервере другая ситуация. А для десктопа это типично.

Вы работали с гиговыми файлами по сетке? ;)

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

Времена Win95/98:

Сын БГ приходит к отцу и говрит: - Папа, покажи что такое многозадачность - Сейчас, сынок, дискету доформатирую

>Что мне не нравится в ext2 (не знаю как в ext3), так это непредсказуемость после перезагрузки Во-первых, это проблема не ФС, а утилиты проверки. Во-вторых, это отключается в конфигах. В третьих, в ext3 проверка диска не производится, просто откатываются неподтвержденные транзакции.

> Когда происходит обращение к свопу проц загружен на 20%, остальные 80% в idle. Я бы предпочел загрузку проца на 40-80% и скорость работы файловой системы в 2-4 раза выше

Кыса, у вас что SWAP НА ФАЙЛОВОЙ СИСТЕМЕ??? Если нет, то запомните - в нормальной системе скорость работы системы при активном использовании swap'а коррелирует только с матожиданием позиционирования на некоторую страницу свопа и скоростью чтения данных с винта. Так что может хватит нести фигню, а?

> А ты в курсе существования коллизий хеша на reiser? Так вот попытается однажды система открыть /etc/shadow, а там порнуха из /usr/portage/distfiles. )))

А вы, кажется, не в курсе, что такое хэшфункции, и каково устройство хэшей. Безотносительно reiserfs, кстати.

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

P.S. Я съехал с XFS на /home после того, как несколько раз после нештатных перегрузок обнаружил в ~/.licq/users/ файлы нулевой длины вместо юзерских данных. Задалбывает, чес-гря, перевбивать контактную информацию.

несколько лет юзаю reiserfs, никаких проблем абсолютно. и скорость фс устраивает и данные не теряются, и после резета не надо вводить рутовый пасс и вручную fsck'ить (до этого конкретно замучался после ребута на редхате 6.2 и 7-м с ext2).

тока один раз винт посыпался на серваке клиентском, потерял пару ненужных файлов из /etc, но всё остальное сохранилось.

ХЗ, пользуюсь рейзером, никаких косяков за ним не замечал....

>Кыса, у вас что SWAP НА ФАЙЛОВОЙ СИСТЕМЕ??? Если нет, то запомните - в нормальной системе скорость работы системы при активном использовании swap'а коррелирует только с матожиданием позиционирования на некоторую страницу свопа и скоростью чтения данных с винта. Так что может хватит нести фигню, а?

Дорогая Даша! Если ты не в курсе, что swap у гимпа лежит в /tmp и временные файлы в ~/.gimp-2.2/tmp, то это не дает тебе право обвинять меня в не компетентности.

> Купил намедни второй веник, стал копировать фильмы с первого на второй (из-под рута, без nice +20. просто cp /aaaa /mnt/sdb1/bbbb). Так вот в это время работать в системе было невозможно. Файловая система (на обоих разделах) - xfs, памяти - 1024Mb, CPU - PIV 3Ghz, винты SATA.

Включи DMA, ослик! ;)

> Понимаю, что забавно, но такую же х..ню я наблюдаю на работе, но с ntfs.

Эта байда, похоже, с SАТА. Было тоже самое (тормоза не пойми из-за чего), когда диск был подключен через переходник... Вот сегодня буду покупать сата-диск и тестировать. Вполне возможно, что прийдется потом менять на pata и покупать дополнительный контроллер.

Открою тебе секрет. SATA диски всегда используют DMA. :P

По крайней мере, так утверждается :)

> Открою тебе секрет. SATA диски всегда используют DMA. :P

Если ядро пересобранно с отключенным DMA для данной MB, тогда - не использует. Тут всё дело в /dev/hands автора. Не может XFS так наклонять систему, что невозможно работать.

Блин, а я-то думаю, чего это так долго у меня на серваке файлопомойки на Reiser3 монтируются.
Просто до неприличия долго...

r01 ~ # uname -a
Linux r01.*** 2.6.14-gentoo-r2 #1 Thu Dec 15 11:40:51 MSK 2005 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

r01 ~ # free
             total       used       free     shared    buffers     cached
Mem:       2044432    1062760     981672          0     251780     270532
-/+ buffers/cache:     540448    1503984
Swap:      2048276         88    2048188

r01 ~ # time mount /mnt/a

real    0m12.137s
user    0m0.004s
sys     0m0.036s

r01 ~ # df -h /mnt/a
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             233G   95G  139G  41% /mnt/a

>Кто может что сказть толковое о jfs, можно её на рабочую станцию, на сервак >ставить?

на моей машинке она стоит, а вот на сервер я бы еще не стал бы ставить.
Судя по списку рассылки там еще фиксят время от времени некоторые вещи,
да и по-настоящему быстрой она стала ИМХО в ветке 2.6, а ее еще ИМХО рано ставить на сервер.

Всем у кого она тормозит советую попробовать на 2.6.x.

>Ну наконец-то независимые тесты подтвердили то, в чем я дааавно убедился на практике!!!

У вас тоже Pentium III 500MHZ?

>У вас тоже Pentium III 500MHZ?

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

>А ты в курсе существования коллизий хеша на reiser? Так вот попытается однажды система открыть /etc/shadow, а там порнуха из /usr/portage/distfiles. )))

Бред сивой кобылы. Коллизия хешей лишь слегка замедлит работу, но не более того.

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

3-х глоловый змий нужен ИМХО Поставьте форточки на пару гигов оперативки NTFS рулит :)))

> Если ты не в курсе, что swap у гимпа лежит в /tmp и временные файлы в ~/.gimp-2.2/tmp

Про это я тоже в курсе.

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

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

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

>ХЗ, пользуюсь рейзером, никаких косяков за ним не замечал....

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

CPU: Pentium III 500MHZ

Вполне возможно, что доисторическая файлуха ext2 выигрывает на доисторичесом проце PIII 500 :). Как увидел, что у них reiser4 10000 пустых директорий 2 мин удаляет - долго смеялся :)). При этом особенно смешно выглядят заявления о большом потреблении проц-го времени с таким убогим процом :).

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

> Файловая система (на обоих разделах) - xfs, памяти - 1024Mb, CPU - PIV 3Ghz, винты SATA.

у меня система чуть по проще (P4 2400@3000, 512RAM, винты SATA - fat32 и reiserfs 3) - при копировании фильмов с одного на другой (в любую сторону) наблюдается только легкое притормаживание, но если машину не трогать, то весь кеш забивается копируемыми фильмами и первые несколько минут, пока используемые программы не вернутся в память, тормозит жутко

Наблюдаю жуткие тормоза на RaiserFS и SATA винте (проц грузится iowait) Списываю всё на сырость реализации SATA в ядре

> Поставьте форточки на пару гигов оперативки NTFS рулит :)))

здесь супер-тормоза не обсуждаются

> Наблюдаю жуткие тормоза на RaiserFS и SATA винте (проц грузится iowait) Списываю всё на сырость реализации SATA в ядре

наверно не SATA, а конкретных контроллеров

только что сделал простенький замер линейной скорости (копирование фильмов, каждый раз фильмы разные, файлы КРУПНЫЕ - 500 - 700 MB, pata винт практически забит)

sata+reiser => pata+fat32 - 10MB/s

pata+fat32 => sata+reiser (внутренняя область винта, т.е. самая медленная часть) - 20MB/s

pata+fat32 => sata+ext3 (середина винта) - 22MB/s

pata+fat32 => sata+fat32 (внешняя часть винта) - 21 MB/s

у меня мать ASUS P4P800 (i865)

> ...но если машину не трогать, то весь кеш забивается копируемыми фильмами и первые несколько минут, пока используемые программы не вернутся в память, тормозит жутко

/proc/sys/vm/dirty_ratio -- поиграйся, он отвечает насколько можно забивать память "грязными" (не синхронизированными с диском) данными. И elevator=cfq тоже наш друг. Даже на сервере. По тестам, не помню кого, Oracle при интенсивном общении с диском на чтение/запись хорошо себя ведёт с cfq, при более интенсивном чтении немного выигрывает deadline.

> А ты в курсе существования коллизий хеша на reiser?

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

> Так вот попытается однажды система открыть /etc/shadow, а там порнуха из /usr/portage/distfiles. )))

Так вот куда ты ее прячешь! Чтоб никто не догадался да? ;)))

P.S.

> A hash invented by Yury Yu. Rupasov. It is fast and preserves locality, mapping lexicographically close file names to close hash values. This option should not be used, as it causes a high probability of hash collisions. [...]

Налицо явное непонимание написанного, то, что коллизии существуют и их вероятность зависит от выбора хешь функции, вовсе не значит, что коллизии никак не разрешаются. Вопчем, не беспокойся. Я уверен, что все с твоей порнушкой будет нормально. ;)

У меня на Celeron 850 reiser4 работает отменно и не падает. Учитесь, господа!

>> Поставьте форточки на пару гигов оперативки NTFS рулит :)))
> здесь супер-тормоза не обсуждаются
Вы пытаетесь распространить заведомо ложные сведения.
Можете разъяснить побудительные причины?

>в ядре включаешь все
>device drivers->block devices->IOShedulers
>а потом ядру при загрузке передаешь дефолтный
>для лило это будет так
>append="elevator=cfq"
>смотришь потом append="elevator=следущий"
>для раб. станции рекомендую cfq

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

>P.S. Я съехал с XFS на /home после того, как несколько раз после нештатных перегрузок обнаружил в ~/.licq/users/ файлы нулевой длины вместо юзерских данных. Задалбывает, чес-гря, перевбивать контактную информацию.

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

<наконец-то кто-то развенчал миф о суперскорости райзера>

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

<А вы сами тестировать не пробовали? Аль за вас все дяди сделают? Наивные... Я сам тестировал ext3, reiserfs, reiser4 и могу сказать, что НА МНОГИХ операциях reiser4 быстрей в РАЗЫ.>

Я несколько раз по разным поводам описывал такие же тесты на лор-е, и я так же получал разницу по скорости в разы

<> It actually takes minutes to hours mounting a ReiserFS filesystem on a large RAID >

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

Винты были скази, нормальные серверные винты.

В аналогичных ситуациях рейзер никогда ничего подобного не делал.

<Ну наконец-то независимые тесты подтвердили то, в чем я дааавно убедился на практике!!!>

А я значит был зависимым тестером да, когда фиксировал обратное ?

Если бы ты был внимателен к тому, что пишут другие или сам бы сделал такие тесты - ведь совсем не тривиально когда коворят, что есть разница по скорости в разы, на довольно быстрых файлухах линукса, есть чему заинтересоваться не так ли - то понял бы, что РЕЙЗЕР4 НА МАШИНАХ ВЫШЕ НЕСКОЛЬКИХ ГИГАГЕРЦ ПОТРЕБЛЯЕТ ОКОЛО 70% CPU. Тебе это ни о чем не говорит ?

Что будет узким местом при работе с компом, у которого слабенький cpu ?

Да странный этот рейзер: у одних без проблем работает, у других файлы портятся. У меня при копировании многие rpm-ки были битые. Советовали tail отключать, но тогда одно из наиблее значимых преимуществ рейзера теряется. Давно сижу на ext3 - надежно! Кто что скажет по этому поводу?

> А вы сами тестировать не пробовали? Аль за вас все дяди сделают? Наивные... Я сам тестировал ext3, reiserfs, reiser4 и могу сказать, что НА МНОГИХ операциях reiser4 быстрей в РАЗЫ.

А можно получить ПОДРОБНУЮ инфу об этих тестах? А то я бы тоже потестировал.

> Да странный этот рейзер: у одних без проблем работает, у других файлы портятся. У меня при копировании многие rpm-ки были битые.

Проблема не в reiser, я его использовал с самых ранних версий, когда глюки были горой. Такого откровенного гонева не было. Недавно наблюдал в гостях, WinXP/SP2, копировал дистрибутив одной софтины с внешнего винта на внутренний, и устанавливал. Инсталятор пожаловался, что .cab битый. Скопировал _ещё_ раз. После этого всё стало нормально. И дело тут явно не в FAT/NTFS, ведь правда? Проблемы железок бывают такие разные...

Хорошо, но почему тогда на ext3 на том же железе проблем не было?

> Инсталятор пожаловался, что .cab битый. Скопировал _ещё_ раз. После этого всё стало нормально.

От таких компьютеров избавляться надо, как от чумы. Без шуток. У меня точно такая же ситуация была под Линуксом - так что windows тут не причём. Я до сих пор не знаю, что барахлило на том компьютере, но при копировании внутри одного жёсткого диска большого файла иногда портился один бит - это мог быть глюк CPU/RAM/MB/HDD - всё, что угодно. Testmem никаких странностей не нашёл, компьютер не был разогнан.

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

Хватит, беспредметной болтовни! Надёжность ФС в статье не обсуждалась.

То что рейзер дает большую нагрузку на проц обсуждалось еще при разработке v4, когда она глубокой альфой была. Статью в топку, надежность интересует.

> Статью в топку, надежность интересует.

Прочитай первый комментарий и брось reiserX/XFS в топку.

у меня reiser3 стоял на 'сервачке' старом, который последние пару месяцев чуть ли не по 3 раза в день перезагружался из-за блока питания. Я честно говоря даже не надеялся что-то там увидеть - однако всё вообще без проблем, reiserfsck лечит хорошо.. данных никаких не потерял.

Было уже раз 100 выкладывание - опять всё вернулось на круги своя. 8) И я, кстати, тоже за рейзер 8) ...

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

Только идиоты ставят Gentoo на сервер, и вдвойне идиоты хранят данные на Reiser-е.

>У меня на Celeron 850 reiser4 работает отменно и не падает. Учитесь, господа!

может у вас еще и винда не падает?

>Купил намедни второй веник, стал копировать фильмы с первого на второй >(из-под рута, без nice +20. просто cp /aaaa /mnt/sdb1/bbbb). Так вот в >это время работать в системе было невозможно. Файловая система (на >обоих разделах) - xfs, памяти - 1024Mb, CPU - PIV 3Ghz, винты SATA.

Не могу подтвердить. у меня xfs дома, на обычном P-ATA и на сервере (5*250Gb SATA). И там и там -- прекрасное быстродействие (из чисто бытового примера: xfs единственная фс, допускающая безсбойное копирование фильма с mini dv камеры, по файрвайр, без остановки прочих работ). кстати, и обсуждаемый тест не вполне корректен -- достаточно начать тестирование не одним, а несколькими потоками(процессами). одновременно обращающимся к винтам, чтобы результаты существенно поменялись, и xfs уверенно вышла на первое место.

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

Кстати, под os/2, jfs уверенно показывала прекрасные результаты именно в "многозадачной ситуации". Год назад -- тестировал -- реализация jfs под линукс, была в этом смысле, сильно хуже тогдашней xfs-реализации. Надо будет попробовать ещё раз, как руки дойдут.