Удача продолжает отворачиваться от проекта ReiserFS (http://www.namesys.com/). В дополнение к упорному нежеланию (http://kernelnewbies.org/WhyReiser4IsNotIn) включать Reiser4 в состав Linux ядра, от ReiserFS отвернулся один из основных приверженцев - SUSE Linux.
В Linux дистрибутиве SUSE уже почти семь лет файловая система ReiserFS используется как ФС по умолчанию. Принято решение (http://linux.wordpress.com/2006/09/27/suse-102-ditching-reis.../) начиная с OpenSUSE 10.2 в качестве основной ФС перейти на ext3, мотивируя поступок фактическим прекращением развития ReiserFS 3, техническими проблемами с масштабируемостью и производительностью, а также стремлением к упрощению поддержки дистрибутива.
По словам Jeff Mahoney из SUSE Labs, файловая система Ext3 не лишена проблем с производительностью, но отлично масштабируется на высоконагруженных системах, используется в большинстве Linux дистрибутивов, имеет четкий план развития и поддерживается существенно большим сообществом разработчиков.URL: http://linux.wordpress.com/2006/09/27/suse-102-ditching-reis.../
Новость: http://www.opennet.me/opennews/art.shtml?num=8462
Удача отвернётся, если работать будет медленно и плохо.А это всё чепуха.
кому надо, тот давно прикрутил себе райзера№4
какая разница, что стоит по умолчанию?
Это не удача, это думать надо головой вместо того, чтобы надеяться на удачу.Сузешники давно и судя по всему -- довольно отчаянно пытались спрыгнуть с третьего рейзера, им пришлось даже поддерживать его фактически самостоятельно (Ганс заявил о прекращении поддержки rfs3, когда четвёртая версия даже по версии namesys.com в продакшн не годилась).
Один знакомый поставщик NAS, который в своё время платил туда денег (даже был в credits, откуда потом был изъят -- что тоже показательно), как-то рассказывал вкратце грабли при работе с Гансом. Т.к. дело было несколько лет тому => как минимум помню вовсе не в деталях, то наводить тень на плетень не буду, но осадок есть вполне чёткий -- reiserfs используется там же, где и RAID0, бишь быстро и пофиг. Где быстро критично и хорошее питание, там XFS (как и у того поставщика NAS). Где надо выживать -- вот там ext3, которая жуткий тормоз даже с -O dir_index (как bzzz в своё время на #altlinux сказал, это уже из-за отсутствия delayed allocation, которым пока пахнуть и не собирается).
Но XFS без UPS -- это вилы.
>Это не удача, это думать надо головой вместо того, чтобы надеяться на
>удачу.
>
>Сузешники давно и судя по всему -- довольно отчаянно пытались спрыгнуть с
>третьего рейзера, им пришлось даже поддерживать его фактически самостоятельно (Ганс заявилСтранно почему так хвалят XFS, я тут тоже купился на обещание онлайнового дефрагментатора и поставил на /home вместо обычного reiserfs 3.6. По бенчмаркам всяким вроде XFS неплох но на самом деле весь десктоп заметно "потяжелел". Дождусь дисков с федорой 6 и поставлю /home на reiser4, а может и /, фиг с ним с selunux, а шустрый комп это для меня важно. Reiser4 постоянно года полтора уже работает на втором компе - файлопомойке. Ни одного глюка. Наверно потому что там нет, не было и никогда не будет SUSE ? :)
>Странно почему так хвалят XFS, я тут тоже купился на обещание онлайнового
>дефрагментатора и поставил на /home вместо обычного reiserfs 3.6
Извините, оно же серверная и high-end workstation ФС. Попробуйте на рейзере одновременно лить чего-нить на диск по сети и одновременно погрузить с него штуки три софтинки (или данные в них в несколько потоков), потом -- на xfs. Бишь для персонального компьютера именно в этом смысле слова оно непрактично совсем (бесперебойника нет, а потом фотки и mp3 с нулями унутре; а плюсы не ощущаются, поскольку серьёзной нагрузки нет).
>Но XFS без UPS -- это вилы.
Можно поинтересоваться в чем ? Я помню только один случай когда я потерял данные. И это был только один файл. Который я редактировал в тот момент пропадания света. Потом журнализированные файловые системы гарантируют поддержку целостности метаданных, а не целостность данных :)
>>Но XFS без UPS -- это вилы.
>Можно поинтересоваться в чем ? Я помню только один случай когда я
>потерял данные. И это был только один файл. Который я редактировал
>в тот момент пропадания света. Потом журнализированные файловые системы гарантируют поддержку
>целостности метаданных, а не целостность данных :)
Суммы остальных сравнивали? У xfs просто есть такая security feature -- когда (гру гря) непонятно, а не чужой ли это был блок, данные зануляются. Метаданные при этом в ажуре, файлик выглядит как живой, а внутри могут быть нолики. Полностью или куском.Дома на /var/ftp напарывался с тех пор, как батарейка померла, а новую добыть -- всё некогда озадачиться :-(
>Суммы остальных сравнивали? У xfs просто есть такая security feature --
>когда (гру гря) непонятно, а не чужой ли это был блок,
>данные зануляются. Метаданные при этом в ажуре, файлик выглядит как
>живой, а внутри могут быть нолики. Полностью или куском.
Хм. честно говоря сталкивался один раз. В целом все верно. Хотя почему они при этом файл не пристреливают? И такое думаю возникает при интенсивном копировании. Ну а тут в целом без хорошего UPS не обойдешься :)
>И такое думаю возникает при интенсивном копировании.
Да вот бродят какие-то невнятные подозрения (что самое паршивое, местами коррелирующие со своими), что бывают случаи, когда гробятся открытые только на чтение файлики.Собственно, это не к тому, что сакс (среди разного сакса этот -- один из двух наименьших IMO :), а в качестве граблелоции на всякий. Кстати, там в 2.6.последних пробегала какая-то грабля, последствия которой не-самый-последний xfs_repair переварить не мог.
> Я помню только один случай когда я потерял данные. И это был только один файл.
> Который я редактировал в тот момент пропадания света.купил упса за 30 баксов - и перестал потеть.
почему-то видеокарта за 80 считается нормой, никого не пугает.> Потом журнализированные файловые системы гарантируют поддержку целостности метаданных,
> а не целостность данныхжурнализирование - бред сивой кобылы. проще убрать вообще буфер, писать сразу всё на диск.
никакого риска, ничего не исчезнет! и уже давно есть - это FAT. просто выключаешь машину
без проблем.ешё один яркий пример того, как сильно успех зависит не от хорошего технического решения,
а от количества баранов, которые за тобой побежали. немного восторженного пиара - и готово.
два года назад ругался с одним пингвинологом, пытался у него выяснить, чем же райзер так хороша.
а так как этот баран был званием старше, пришлось из проекта уйти. и слава богу, - с баранами бодаться - только время терять.
>> Потом журнализированные файловые системы гарантируют поддержку целостности метаданных,
>> а не целостность данных
>журнализирование - бред сивой кобылы.
Да-да, поэтому всем полчаса бояться, делать фоновый fsck и ни разу не нарываться на рейсы. Это бредом ни разу не будет.>проще убрать вообще буфер, писать сразу всё на диск.
Проще, да вот медленно только. Бишь обычный tradeoff, в данном разе -- производительность/надёжность.Надо сказать, один вовсе не глупый знакомый (Андрей Зубинский) как-то меня немало удивил, перебравшись [назад] на BSD и... врубив sync. При сборке диск действительно напоминал фрезу по звуку. Доктор, это часто случается?
>никакого риска, ничего не исчезнет! и уже давно есть - это FAT.
>просто выключаешь машину без проблем.
Андрей, Вы наивны, как ребёнок, который матерится и думает, что это делает его старше.Не путайте слои. Даже в DOS были дисковые буферы (BUFFERS, что ли -- по Ctrl-Break ещё сбрасывались, вместе с информацией о смене дискеты от привода). Даже в DOS бывали дисковые кэши в RAM (как их... а, тот же SMARTDRV).
То, что FAT примитивен, не есть панацея данным, которые до него просто не долетят. Даже если вынести вроде как сейчас обычно отключенный из коробки кэш по записи на HDD, которого в те времена попросту не было.
>два года назад ругался с одним пингвинологом, пытался у него выяснить, чем
>же райзер так хороша.
Не, ну и у этой ФС хватает своих хороших сторон, и у меня почему-то есть подозрение (не основанное на опытном сопоставлении в течение продолжительного использования, поэтому именно подозрение), что UFS/FFS и до неё по поведению в этих самых критических ситуациях -- как пешком до луны. Особенно два года назад, когда тут народ регулярно смахивал скупую мужскую слезу по части softupdates.Скорость обусловлена в т.ч. грамотной организацией метаданных деревьями (b*, что ли -- сам как-то ничего умнее btree не применял), хорошо, что уже даже до ext3 это дело дотащили.
Надёжность -- шут его знает, см. комментарий рядом про клубы. Практика в больших объёмах.
>и слава богу, - с баранами бодаться - только время терять.
Эт правильно.Вот только если сравнивали с парулетназадними бздюшными ФС, то кто же был бараном -- вопрос в лучшем случае открытый.
>купил упса за 30 баксов - и перестал потеть.
Тогда уж не один и не один блок питания. Для надежности. У меня так сервер БД живет. И Потом нормальный UPS стоит далеко не 30 баксов.>журнализирование - бред сивой кобылы. проще убрать вообще буфер, писать сразу всё
>на диск.
И словить жесткие тормоза. Очень жесткие тормоза.>никакого риска, ничего не исчезнет! и уже давно есть - это FAT.
>просто выключаешь машину
>без проблем.
Мдя ? Давно флешку просто так без выполнения каких либо дополнительных процедур выдергивали ?>ешё один яркий пример того, как сильно успех зависит не от хорошего
>технического решения,
>а от количества баранов, которые за тобой побежали. немного восторженного пиара -
>и готово.
Журнализирование хорошее техническое решение.>два года назад ругался с одним пингвинологом, пытался у него выяснить, чем
>же райзер так хороша.
Reiserfs неплоха, но не слишком стабильна и не слишком хорошо масштабируется.>а так как этот баран был званием старше, пришлось из проекта уйти.
>и слава богу, - с баранами бодаться - только время терять.
Знаете по вашим высказыванием мне вот кажется все несколько наоборот. :)
а чем ext2 не устраивает?
>а чем ext2 не устраивает?
По'fsck'йте сотню гиг хотя бы. Бишь совсем немного.
120+160 гиг чекает минут за 5работает быстро, к вырубанию питания устойчив (проверено неоднократно)
убедите меня зачем мне нужен рейзер (пользую слаку, где поддержка рейзера есть по умолчанию)
>120+160 гиг чекает минут за 5
Под ext2? Гм, надо будет попробовать. Последний раз, как сталкивался, это были максимум десятки гиг и минимум десятки минут, что-то такое помнится. А несколькитерабайтные массивы и под ext3-то *форматируются*, не то что проверяются, слишком долго (со слов коллеги, который у нас по кластерам).Есть мнение старших товарищей, что ext2 хороша для хранения данных, которые может понадобиться из неё выколупывать (отчасти потому, что "простая как двери"). Других плюсов мне на сейчас неизвестно.
>работает быстро, к вырубанию питания устойчив (проверено неоднократно)
>убедите меня зачем мне нужен рейзер (пользую слаку, где поддержка рейзера есть
>по умолчанию)
А, ну слакваристов убеждать вообще в чём-либо бесполезно. Пользуйте.PS: по части устойчивости к вырубанию и ресетам, особенно на паршивом железе навроде некоторых провинциальных компьютерных клубов, Женя Остапец несколько лет рекомендовал именно рейзер-3.6 (аккурат по богатому опыту внедрения по таковым).
>А несколькитерабайтные массивы и под ext3-то *форматируются*, не то
>что проверяются, слишком долго (со слов коллеги, который у нас по
>кластерам).какуюто вы ахинею несете...
/dev/sdc1 1.2T 503G 632G 45% /usr/hosting_files_raid10umount /dev/sdc1
time mke2fs -m 1 -O sparse_super /dev/sdc1
...
real 2m25.686s
user 0m0.956s
sys 1m15.473s/dev/sdc1 1.2T 205M 1.2T 1% /usr/hosting_files_raid10
даже если у вас на пару секунд будет быстрее - не проблема, не так часто форматируются разделы, а если система чистая (что обеспечивается двойным журналированием - метаданных и самих данных) - то и проверка занимает секунды. согласен XFS быстрее. но надежность важнее!!! не припустимо "потерял всего один файл".
>что обеспечивается двойным журналированием - метаданных и самих данных
>
простите ... это вы про ext2 ?
>>А несколькитерабайтные массивы и под ext3-то *форматируются*, не то
>>что проверяются, слишком долго (со слов коллеги, который у нас по
>>кластерам).
>какуюто вы ахинею несете...
Повторюсь -- со слов коллеги. Я сам немного удивился, но IIRC он упоминал что-то вроде шести часов на массив. Вот где оно лежало и сколько там было теразов -- не знаю, поскольку он ещё и взрослыми стораджами занимается.(общеизвестные жуткие тормоза mkfs.ext3 при отсутствии IDE DMA мы с негодованием отметём как абсолютно иррелевантный к стораджам факт)
забудь про рейзер 3, он уже не поддерживается, при этом до продакшен-качества так и не доведён
250 серваков
на всех разделах - xfs
за все время - ни разу не терялись файлы даже когда надо ребутили по overloaded на винт (т.е. активно писались файлы).Ext3 - было несколько случаев когда _просто_ пропадали файлы (без появления оных в lost+found). Причем в ext3 есть дурная привычка восстанавливать файлы в lost+found без сохранения структуры каталогов. Когда юзерских файлов пару миллионов...
xfs восстанавливает со всей структурой.упаси Боже от ext2/ext3 на серваках.... это были кошмарные денечки... появились сединки на моей тогде еще молодой буйной головушке :)
да как бы медленная твоя xfsтесты посмотри - всех делает ext2, и на множестве маленьких файлов - рейзер
естественно, не за счёт того, что она супер, а потому что простая как 2 пальца и без журналирования (бэкапы рулят?)
>да как бы медленная твоя xfs
Да мне это "как бы" неинтересно.>тесты посмотри - всех делает ext2
Я, кажется, объяснил -- fsck.ext2 не вариант.>и на множестве маленьких файлов - рейзер
Рейзер -- /там/ не вариант в куда меньшей степени и по другим причинам, но тем не менее. Он используется, но как правило именно с RAID0 или одиночными дисками.А так -- извините, тесты мне тоже интересны те, которые не для случая "я и моя собачка", бишь отдать один html и пять гифарей с домашней машинки васи-хацкера по модему 33600. А для чего-то поближе к моим проблемам. Не космическим, но и не однозадачным.
Когда тазик прошлого века (Duron 800/512M/IDE), который сполнял до недавнего за ftp.linux.kiev.ua, отдавал до ста мегабит ftp/rsync, при этом было и w ненулевое количество (поскольку почта и местами веб -- там же были) при данных на xfs и как он же просто загибался до чуть ли непингуемости под ext3 при одновременных r и w -- я "как бы" и сам прекрасно помню. И тест на двух идентичных барракудах, расставивший точки над "ы", тоже.
Выглядел он так -- добавились два IDE 120G, на один из них пошла ext3, другой пустой. На первый было перенесено содержимое предыдущей шестидесятки (кажется), которое после подъёма пошло себе отдаваться на несколько DSL и стопку дайлапов -- мегабит десять-пятнадцать в сумме, но оживлённо по потокам. На него же была поставлена заливаться FC4, что ли. Исошками в пределах IX. Пока влезало в кэш -- ~50mbps. Потом LA стрельнул в потолок (то ли за 12, то ли за 40), а пропускная на диск -- упала ниже плинтуса, где-то к пяти мегабитам. И всё безудержно тормозило, хорошо, что оперативно приступил к получению хотя бы reniced shell (ionice там быть не могло в принципе). Так вот то же самое, но на соседнем блине, куда была водружена xfs, прошло *настолько* незаметно для машинки, что я сам сидел и минуть пять глаза протирал -- где дикие тормоза? Где LA и эти самые залипшие в ожидании I/O процессы? Ниже единицы, всё шуршит и радуется жизни.
Вот такие пироги; но с тех пор ничуть не удивляюсь, что для kernel.org потребовались квадовые оптероны с прочими погремушками. С ext3-то, ага. (specially for andr: только не надо мне рассказывать, что а вот бы фря -- в [UF]FS, насколько мне известно, delayed allocation также не пахло, не пахнет и вряд ли в обозримом будущем запахнет, а это тут оказалось ключевым)
PS: у xfs была когда-то ещё заморочка с software raid5, которая гуглится по характерным для неожиданных тормозов сообщениям в логе (про прыгающий размер чего-то, когда stripe size, block size и записи в журнал приводили к специфической ситуации). Впрочем, и это уже вроде неактуально.
как-то неконкретно высказываешьсявопрос по существу:
сервер,
1) который может выключиться в любой момент
2) в котором могут перегреться летом винты
3) в котором может забиться / под 100%может нормально работать под рейзер или [x|j]fs?
люди говорят, что разделы просто сыпятся, как 98 венда после неудачной установки какого-нибудь драйвера :) (сравнение шуточное, конечно)
и тем не менее... если у меня не кластер, а обычный сервак?
сервер,> 1) который может выключиться в любой момент
Это не сервер.
> 2) в котором могут перегреться летом винты
Это не сервер.
> 3) в котором может забиться / под 100%
Это не сервер.> может нормально работать под рейзер или [x|j]fs?
Сервера - да.
га-га-гану вот, добро пожаловать в реальность
у начальника нет денег на конд, у чубайса нет электричества, а админ админит раз в месяц
таких серверов я думаю очень много
>га-га-га
>
>ну вот, добро пожаловать в реальность
>
>у начальника нет денег на конд, у чубайса нет электричества, а админ
>админит раз в месяц
>
>таких серверов я думаю очень много
Да не - обыкновенное (мда...) отсутствие чувства ответственности (на всех уровнях)...
Иногда - и знаний.
>и тем не менее... если у меня не кластер, а обычный сервак?
...то не дай Боже Вам (упомянутому начальнику, ...) потом заниматься "обычным кластером". Мотивируя это богатым админским (управленческим, ...) опытом.
>как-то неконкретно высказываешься
>
>вопрос по существу:
>
>сервер,
>
>1) который может выключиться в любой момент
>2) в котором могут перегреться летом винты
>3) в котором может забиться / под 100%
>
>может нормально работать под рейзер или [x|j]fs?
Да. Работает. И под xfs и под reiserfs. При посыпавшемся винте из xfs данные достаются. У меня не было проблем с доставанием данных с нее. С reiserfs были.>и тем не менее... если у меня не кластер, а обычный сервак?
это у вас не сервер. А дешевый писюк исполняющий роль сервера. В таких условиях у вас должен стоять embedded платформа с флешем. Где никаким рейзером не пахнет.
>да как бы медленная твоя xfs
>
>тесты посмотри - всех делает ext2, и на множестве маленьких файлов -
>рейзеркогда перевел сервера баз данных, скорость чтения поднялась где-то раза в 4
когда перевел сервера free hosing на XFS, LA упала до меньше 1опять же, я говорю _только_ о загруженных серверах
там где скорость отдачи ~50-140mbps.дома - да, xfs на некоторых операциях тормознее (например удаление всего каталога или очень большого файла).
но таких операций на серверах очень мало.
как правило - чтение файлов и записи в базы.
Согласен. ext2 и ext3 - это жуть.В остальном, я на 40 продакшен серверах использую SLES9 SP3 reiserfs3.6 и за 2 года,
режим работы оных 24х7, серьезных проблем замечено не было. А поспать ночью хочется. Если бы reiserfs плохо работала давно бы перебрался на что нибудь другое.НИГДЕ, НИЧЕГО НЕ ПРОПАДОЛО И НИКАКИМИ НУЛЯМИ НЕ ЗАПОЛНЯЛОСЬ. На некоторых из них очень большое колличество файлов и пишут они постоянно и много (колличество файлов в кеш - 10 196 781). А о перезагрузках по ресету я вообще молчу, поскольку, никаких проблем они, также, не вызывали.
Вот статистика которой я доверяю, поскольку испытал на собственной шкуре!
не пробовал reiserfs потому что банально боюсь.
сильно много репортов о проблемах с ней
хотя много репортов о полном отсутсвии проблем с оной250 серваков, 4 года.
сейчас запустил tape backup на 14tb, может и попробую на нескольких серваках
Сам на серверах использую XFS в softraid, указанных проблем с 0 не наблюдал. Но, как мне помнится у рейзера именно проблема с концами файлов, дописывает всяко разное. Да и проблем у меня на одном серваке под рейзером было море, постоянно
появлялись не удаляемые файлы/каталоги, в общем кто хочет нормальной жизни, тот
пользуется XFS/ext3/jfs!
>Но, как мне помнится у рейзера именно проблема с
>концами файлов, дописывает всяко разное.
Так его ж все с -o notail используют давно. Видимо, от ожогов. Ещё смутно припоминается, что это могла быть одна из многих грабель 3.5.Бишь у каждой ФС есть свои преимущества и недостатки, вот только лучше их знать как есть, а не на уровне предрассудков.
Так что если кто знает уже существующее хорошее сопоставление -- забросьте, наверное, ссылку; а если нет -- предлагаю не на форуме, а в wiki по возможности компактно и обозримо обрисовать свой опыт эксплуатации разных ФС в условиях, когда между ними /есть/ разница: http://www.freesource.info/wiki/HCL/XranenieDannyx/Sravnenie...
С 2001 пользуюсь рейзером. На серверах уже перешел (где можно) на xfs.
Проблемы с рейзером (меньше одной руки) были только по причине железа.
С и без notail - проблем не было.
Вот такой вот опыт.
Кстати, про производительность. Понятно, что там, где терабайтные массивы, xfs сильно впереди.
ext3 3 года назад и сейчас - 2 большие разницы, он стал намного быстрее и предельно вылизан по надежности. Хотя и xfs очень хорош.
Когда перелезал на новый дистрибутив, СentOS4 - ядро 2.6.9 RHEL, то ускорение операций с диском было заметно просто на глаз. Да, там новый планировщик I/O, но ускорились все дисковые операции.
> ext3 3 года назад и сейчас - 2 большие разницы, он
>стал намного быстрее и предельно вылизан по надежности. Хотя и xfs
>очень хорош.
Что то я незаметил преимущества xfs перед reiser4 на больших файлах ( образы DVD 4-9 GB и образы xen ). Ни в теории ни на практике XFS не лучше. Может она крута на hi-end sgi scsi оборудовании где свои фирменные штучки типа всяких барьеров и гарантированных рейтов записи но на моем компе этого нет. Надо бы попробовать хваленую ZFS от Sun, там столько всего вкусного наобещали.
xfs очень хорош там, где есть много параллельных запросов чтение-запись.
Если их нету - то вообще говоря, пофиг, что стоит.
и то, что образы dvd у меня на ext3 удаляются пару сек. - пофиг.
юзаю райзер 3.6 около 2х лет, проблем не замечал... в том числе и без -notail...
Использовал ReiserFS 3.x (в Slackware 10.0).
Всё было хорошо, пока один парень не нажал reset.
Проблема всплыла через несколько месяцев - база не захотела бэкапиться, выборка из определенной таблицы за определенный день оканчивалась сообщением о не правильном формате страницы.
Пришлось тащить табличку вручную, начиная со следующего дня.С тех пор под базу ставлю Ext3, а под всё остальное (где нет интенсивной записи) - reiser, ибо шустр и места меньше занимает.
Да что вы спорите 8) С приходом твердотельных ЗУ (хе-хе, а звучит то как) сопоставимой с теоритическим пределом емкости записи на магнитный носитель, все настоящие (сегодняшние) файловые системы отомрут ;) Не будет механики, не будет износа и проблем с фрагментацией. Так шта, расслабьтесь. Экономьте нервы и возможно доживете до этого миллениума 8)
>Да что вы спорите 8) С приходом твердотельных ЗУ (хе-хе, а звучит
>то как)
Ага, мля, с приходом голографии на кристаллах и т.п. пиндык всем файловым системам.Половина их них просто не ахти а половина такую емкость не поддерживает.В таких условиях нечто типа рейзера с b-tree будет круто потому что мало нагружает проц в процессе работы с большими каталогами информации.А файлов как вы понимаете там будет до**я, линейные списки и прочее технологии там не жильцы.
это рейзер-то мало нагружает проц в "процессе работы с большими каталогами информации" ? бугагагага. бугагага^4 если это SMP.