Насчет файловых систем...

raiser v3.6 2 года полет нормальный

Рейзер.

если надумаешь ставить reiser то запасись UPS'ом иначе из-за проблем с питанием будешь ловить интересные баги типа нестираемых файлов и директорий и терять файлы на ровном месте.

Раз надцать вышибало свет без упса - ничего подобного не наблюдал. Всё фиксится при перезагрузке. Это с ext3 как раз периодически в таких ситуациях вылезает: Filesystem was fixed, but reboot is needed. После этого может и не загрузиться.

У меня с reiser4 нет проблем

А правда что райзер намного быстрее чем ехт2/ехт3?

Reiser3 наше всио. Пока прошлый винт не сдох - работал :) На новом он же.

В случае кучи маленьких файлов (/usr/portage, /tmp) - на порядок.

>2 и пишет что-то типа warning ext2FS fill_super (может чуть не так).

может стоит для начала взглянуть на dmesg и узнать что же она пишет?

да UPS это хорошо но он тож не всесилен, бывает драйверок какой повесица(особено wifi) и систему кромекак жоским халтом не грохнеш поэтому raiser непробую а вот с ext3 нормально.. почекает и загружаеца

может стоит посмотреть в сторону XFS?

reiser4 - 1.5 года!
reset и выключения света были в избытке!
OK!

Большие файлы: Xfs
Маленькие фалы: reiserfs

У меня корень на reiserfs, фильмы и музыка на xfs. Так живу больше года, может уже два. Ниразу ничего не проподало и не ломалось, хотя из розетки комп выдергиваю регулярно.

ext3 не пользуюсь с тех пор как после отключения электричества похерил мою музыкальную коллекцию.

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

reiser

reiser 3.6 - 3.5 года, надежно как ракета-носитель Протон, электричество вырубается часто.

reiserfs с частыми выключениями света, пару раз ловил софт-бэды на винте, которые приходилось "замазывать" с помощью mhdd. Файловая система не умирала.

А вот глюки про нестираемые файлы помнится ловил если монтировать reiserfs то с опциями acl или user_xatrr то без них.

Как то пробегала мысль, что надёжность reiser и ext3 зависит от конкретной конфигурации, иногда надёжнее то, иногда это. Сделайте бэкап и попробуйте. От себя могу сказать, что однажды попробовал поставить рейсер, через 2 дня, после случайного выключения света, он у меня не загрузился. А ext3 стоит уже года 2, в последнее время свет отключают раза 2 в неделю (и обычно компьютер в это время работает), никаких проблем я не видел, поэтому для себя я этот вопрос решил в пользу ext3.

А насчёт скорости файловой системы, вы действительно в повседневных задачах замечаете её влияние? Я лично думаю, что если бы мой диск стал работать на 50% быстрее, на комфортабельности работы это сказалось бы слабо. Конечно если на диске достаточно много свободного места, иначе наверное будут проблемы с фрагментацией.

Рейзер, IMHO, посередине между ext2 и ext3. Последняя - IMHO, вообще говно. А ext2 быстрая, но ненадёжная.

> А правда что райзер намного быстрее чем ехт2/ехт3?

Это распространенный миф. Она быстрее не _некоторых_ операциях, да, но медленнее на других. Вообще, на мой взгляд, важность данных решает: не надо экспериментировать с форматом ФС. Ext3.

>Рейзер, IMHO, посередине между ext2 и ext3. Последняя - IMHO, вообще говно. А ext2 быстрая, но ненадёжная.

А разве ext3 это не ext2 + журнал? Что насчет меня, долго сидел на рейзере, но может из-за того, что я винт 20 форматировал-непереформатировал, а может мне просто не повезло (помните, весной вышел патч 2.6.15.x в котором поправляли ошибку с reiser и ext3), короче только поставил генту, reiser начал жутко кашлят и давиться, приходилось пинать его разными alt+sysrq+t чтобы дозагрузиться, в итоге все это надоело и я откатился на ext3 :) и купил новый винт :) потому что все говорили, что старый умирает...но вот оба держу на ext3, и старый пока очень даже ничего...так что мой выбор ext3, и в будущем либо ext4 либо reiser4 если его официально включат в ядро.

На практике разницы почти никакой. У меня ноут одно время глючил и вырубался от перегрева раза по три-четыре в день, так и рейзер и ехт3 выдерживали нормально, ничего не теряли, никаких нестираемых файлов. Система - АрчЛинукс 0.7.2, всё дефолтное, никаких хитрых настроек. На мой взгляд проблема надуманная.

>Раз надцать вышибало свет без упса - ничего подобного не наблюдал. Всё фиксится при перезагрузке.

Из личного опыта делать заявления, что если у меня не ломалось, то не ломается вообще -- это грех :) Могу заявить, что после резкого отрубления питания reiser 3.6 завалил открытый в этот момент файл (причем сохраненный), и после перезагрузки и чека там оказался кусок /etc/fstab и больше ничего. Кстати, подобные проблемы репортились и тут в форуме где-то. После этого случая я попрощался с reiserfs. Так что пока у меня XFS. Но ложка дегтя есть пока и в XFS. Я столкнулся с такой проблемой, но пока так и не стал лечить (из-за боязни порушить все к чертям собачим): http://www.linux.org.ru/view-message.jsp?msgid=1359502

P.S. Мне лично интересен прогресс в JFS. Никто не поделится опытом? Мне негде ставить "на попробовать".

>то после резкого отрубления питания reiser 3.6 завалил открытый в этот момент >файл

И что?
Транзакции работают только с metadata в почти во всех журналируемых ФС,
если вы хотите чтобы и данные в откртых файлах были в нормальном состояние,
то по-моему это может только ext3: data=journal

>P.S. Мне лично интересен прогресс в JFS. Никто не поделится опытом? Мне негде >ставить "на попробовать".

у меня уже год стоит на домашней машине, вначале было заметно быстрее
по сравнению со стоявщей до этого ext3, возможно в силу фрагментации.

Нормально отрабатывает нештатные перезагрузки,
тесты из ltp прошел,
но на мой взгляд все-таки xfs и reiser4 работают по быстрее,
если бы еще были так же надежны.

Просто заюзай ext3. Она стабильна...ну может и не так прямо супер-мега стабильна, но все же постабильнее чем reiser*

>И что?

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

И вспомнил вот еще что. Повторялось с завидной регулярностью. Файлуха XFS. при определенной настройке видеокарты (экспериментировал) намертво вешались иксы. То есть только Reset спасал. Порядок был такой: редактируется xorg.conf в nano, потом *записывается* и терминал закрывается, потом перезагрузка иксов. Иксы повисают. Reset. После перезагрузки размер xorg.conf становится равным 4096 байт, а в нем -- мусор. Вот так. Если возникает вариант кривых рук, то это, наверное, надо мэйнтейнерам Debian сообщить, что они лохи. :)

Или это карма такая. Но все-таки про стабильность 100%-ную я бы поостерегся говорить. Это очень смело. Просто пока везет, у кого не возникла ситуация. :)

>Порядок был такой: редактируется xorg.conf в nano, потом *записывается* и терминал закрывается, потом перезагрузка иксов.
Рекомендую после редактирования sync
И еще, в dmesg есть такая строчка?
hda: cache flushes supported
если такой строчки нет, а есть "not supported", то обязательно делать sync перед экспериментами.
Кое-кто в тут предупреждал:-)

>Я же написал, что файл был *записан*, а не просто открыт и не сохранен.

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

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

Да, наивно полагаю. Именно так. И считаю это полагание правильным. Раз записал, то должен быть на диске. И точка.

>Рекомендую после редактирования sync

На самом деле, для xfs, по-моему, какие-то параметры есть в /proc/sys/fs/xfs. Там таймауты age_buffer_centisecs, xfssyncd_centisecs, xfsbufd_centisecs. Их минимально можно убрать в полсекунды. Ниже не позволяет.

Для дома, для семьи: корень, хомяки, var - все на reiser 3.6, данные типа фильмов, музыки и прочей манги - xfs, обязательный UPS. Еще сервачок (ака роутер+почта+... домашний такой, короче) в тихом и уютном месте, тоже ups, но ext3 на корень и xfs на данные.

Работа, продакшн: либо солярный нативный ufs, либо редхэтовый ext3 и никак иначе, а UPS'ы неплохо бы еще ставить в избытке + генератор...

Полет дома... сервак работает с 0.15 уже года 4-4.5, WS - хз, куплена полгода назад :), но глюков не было...

P.S. kernel = vanilla + 2.6.xx.yy.patch

> Да, наивно полагаю. Именно так. И считаю это полагание правильным. Раз записал, то должен быть на диске. И точка.

На чем основывается данная уверенность и какие обоснования приводятся? Дописать "sync,data=journal" в /etc/fstab мешают религиозные соображения, если уж все так критично? Или vim/nano пропатчить на вызов sync(), после write()?

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

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

>data=journal xfs этого параметра не имеет. Это только, по-моему, у ext3. Тем-то она и лучше, что потерять данные, ИМХО, труднее.

Ну "sync", man mount короче, это именно оно - весь ввод-вывод синхронен.

"О какой вообще сохранности данных можно говорить, когда постоянно падает питание, а ФС даже не смонтирована синхронно?" (С) В FAQ.

"data=journal" есть у ext3/reiserfs точно, и кажется (крайне не уверен) у jfs - так вероятно лучше использовать более надежные средства, если уж так стоит вопрос?

> Но скажи мне на милость, о какой тогда надежности при исчезновении питания >можно говорить?

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

и при загрузке не требуется долгий fsck,

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

ЗЫ

vim вызывает fsync, после ":wq",
а reiser недавно пофиксиили баг, приводищий в 50% случаев
к потере данных в сценарии:
1)fsync
2)перезагрузка

ext3 как раз из-за журнала и тормозит

> > А правда что райзер намного быстрее чем ехт2/ехт3?

> Это распространенный миф. Она быстрее не _некоторых_ операциях, да, но медленнее на других.

Мне хватает операции копирования.
Лично тестил на обычном секундомере (разархивирование исходников OpenOffice)
В порядке увеличения времени: reiser4, reiser3.6, xfs, ext3, ext2

лучше пользуйся ext3 дальше.

без упса на рейсере действительно хреново... Ну как хреново - 4 года говнороутер без упса стоял - и ничего, а вот примерно мес назад появилась куча нестираемых файлов. Хорошо что home со всякой фигней...

Я теперь на домашних компах буду использовать только ext.

... или упс покупать)

На самом деле надо просто перед экспериментами набрать в консоли
~/$ sync<enter>
файло окажется на диске. Можно 2-3 раза для пущей уверенности.

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

XFS круче всех на больших файлах, но _невероятно_ тормознута на куче мелких. Причем даже не то, чтобы на куче -- начиная с сотен!

Райзер под нагрузкой глючит. Проверено на массе различных комбинаций железа и софта. Не шибко глючит, но ощутимо и разнообразно.

ext3 в глюках не замечена.

>намертво вешались иксы. То есть только Reset спасал.

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

Кстати о птицах - глянул нынче в собственные незнамо когда написанные скрипты отмонтирования ФС при шатдауне - там аж 4 раза вызывается "sync" (до отмонтирования, после отмонтирования nfs, после локальных, после всего остального на корне перед самым шатдауном), плюс штатный acpid позволяющий корректно завершать работу системы при блокировке клавы-мыши... может быть именно поэтому я и говорю о "стабильности" ФС и сохранности данных...

Ну дык и я про то же: о какой "стабильности" ФС можно говорить, когда зависшие иксы ресетом "лечатся"?

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

Да и логику "ниасилил" - каким боком зависания Х11 в ФС, не в курсе ;)