Вообще ССЗБ. Прикрути журнал к своей ext2.

man tune2fs

iso9660

Use ReiserFS - ReiserFS save your information and solve your problems!

fat32 в режиме ro спасёт тебя, любитель НеТуЭфЭс

потрея данных зависит не только от фс но и от качества винчестера

поставь себе / ro и радуйся, краха не будет...

Спасибо уже так спас, что пришлось часть торентов снова выкачивать.

Если отключения редки, журналируемая ФС + регулярное резервное копирование важных данных обычно достаточная мера. Если часты — ИБП.

ext2 по надёжности из той же эпохи, что и fat - журнала нет, надёжности при отказе питания почти никакой.

хорошо известные аналоги ntfs (по надёжности) - reiserfs и ext3 - журнал есть и работает хорошо.

PS. Больше не сравнивай ext2 с ntfs

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

"Уж 200 раз твердили Сене,
Бэкап спасёт от удаления.
А кто ж его создать поможет?
Кронтаб и ман, тупая рожа"

(С)anonymous кажись


В принципе, тут добавить больше нечего... А про надёжность НТФС это будешь на конфах МС заливать... Последней каплей перед удалением маздая было то что он гробанул после БСОДа раздел на 60Гиг... правда у меня почти всё было забекаплено, кроме пары гамесов, но грохнул я тогда мастдай и не жалею :)

Reiserfs =)

reiserfs

>Иногда случаются такие неожиданности...

Молодец, и я никогда не стесняюсь.

P.S. Бесперебойник

> Как сделать файловую систему надежной? И при этом желательно не сильно потерять в скоростях.

ext2fs имеет смысл использовать только на очень слабых машинах.

Пользуйся журналируемыми ФС.

ext3 + data=journal в /etc/fstab

> ext3 + data=journal в /etc/fstab

Не надо ext3. И уж тем более не надо data=journal. Потому как

1. Это самый верный способ напороться на глюк. Объяснение см. здесь:
http://kerneltrap.org/node/7518
Прмер глюка: http://bugzilla.kernel.org/show_bug.cgi?id=9692

2. Потеря по производительности отнюдь не маленькая.

Самый безопасный секс — секс по телефону.

ФС, надежно защищенная от сбоев -- iso9660.

> благодаря довольно высокой надежности файловой системы NTFS.

Эвон как. Надо будет рассказать об этом в следующий раз, когда меня кто-то
из "счастливых" пользователей этой чудо-ФС попросит восстановить данные.
Боюсь, правда, что шутку не оценят, и дадут по морде.

Не найдете Вы такого .овна, как NTFS. Даже уродина ext3 -- и та надежнее
(если не баловаться экзотическими опциями mount и mkfs).

Уже раз 5 или 10 вырубалось електричество и reiserfs усердно скрипя дисками при загрузке отлично все восстанавливал.

З.Ы. А Ханса всеравно жалко...

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

raid + backup. Желательно offsite. Все остальное - паллиатив.

Евреи, не жалейте заварки (C)

> raid + backup.

backup -- это правильно. А raid на домашней машине, IMHO, нафиг не нужен.
Ибо программный мало что меняет, а правильный аппаратный (с батареечкой)
шибко дорого стОит. А OP даже на бесперебойник денег жалеет, а не то что
на "лишний" диск или нормальный RAID контроллер.

>Эвон как. Надо будет рассказать об этом в следующий раз, когда меня кто-то из "счастливых" пользователей этой чудо-ФС попросит восстановить данные.

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

>Не найдете Вы такого .овна, как NTFS

Я уже рассказывал, как однажды по-горячему поменял HDD в реке, забыв отмонтировать. С NTFS на другую NTFS, даже с другой геометрией. И фильм писать начал... Спохватился только когда ошибку выдало. На новом HDD весь каталог от старого рисовался. Ничего, chkdsk вылечил всё. Ничего не пропало :)

...

Собственно, меня пока две ФС не подводили пока никогда. ReiserFS и NTFS. Но со второй у меня практика была раз в десять шире...

>Но со второй у меня практика была раз в десять шире...

И я ReiserFS никогда не использую в таких жёстких условиях, в каких использовал раньше NTFS :)

> Уже раз 5 или 10 вырубалось електричество и reiserfs усердно скрипя дисками
> при загрузке отлично все восстанавливал.

Журналируемые ФС "восстанавливают" (в идеале) метаданные. Какая-то часть
данных неминуемо пропадет (ext3, правда, пытается журналировать и данные,
но пока что от этого больше вреда, чем пользы). Какая-то -- становится
бесполезной. Пример:

tar czf foo.tgz -C ~/foo .

и в этот момент пропадает питание. После перезагрузки foo.tgz можно выкрасить
в зеленый цвет и стереть.

Смысл журналирования не в том, чтоб "все восстановить". А в том, чтобы
избежать fsck (который при современных размерах дисков уж очень долго
будет выполняться).

> Неужели восстановить данные под NTFS сложнее, чем под ReiserFS? :)

ReiserFS использую исключительно в качестве помойки. Держу на ней кеш
ccache и прочую лобуду. Случись чего -- восстанавливать не буду.
Восстановлением NTFS занимаюсь исключительно из жалости к братьям (меньшим)
по разуму. И то, делаю только простейшие операции: сдампил в файл, натравил
на образ ntfsfix или anysurrect, если не вышло -- посылал нафиг.

> Мужики, которые восстановлением занимаются, почему-то за первое берутся,
> за второе - фиг :)

За что платят, за то и берутся.

> Я уже рассказывал, как однажды по-горячему поменял HDD в реке, забыв
> отмонтировать. С NTFS на другую NTFS, даже с другой геометрией. И фильм писать
> начал... Спохватился только когда ошибку выдало. На новом HDD весь каталог
> от старого рисовался. Ничего, chkdsk вылечил всё. Ничего не пропало :)

То, что происходит один раз в 100 лет, мало интересно. Интереснее статистика.

>Интереснее статистика.

Статистику я сказал. За бытность мою винадмином я пронаблюдал несколько сотен машинолет работы с NTFS в разных режимах. Юзеровском, нагруженной файлопомойки, web/sql-серверов, переносных внешних девайсов и т.п... Падений не наблюдал ни разу.

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

ext3 - около пяти, наверное, машинолет. Два падения насмерть.

xfs - около двух или трёх машинолет. Падений системы в целом не было, потеря данных - случалась.

Про fat32, думаю, говорить не нужно. Редкий машиногод без сбоев проходит :D

ext2 падала, но очень давно, ещё в конце 1990-х, с тех пор ею кроме как в /boot не пользуюсь.

jfs, ext4 не использовал. reiser4 использую всего дня четыре. udf в пакетном режиме на CD-R/RW крайне ненадёжна.

Вроде, всё упомянул :) Экзотика, типа FAT12, CP/M, TR-DOS, БК-0010, полагаю, не в счёт :D

>З.Ы. А Ханса всеравно жалко...

А его жену?

>ext2 по надёжности из той же эпохи, что и fat - журнала нет, надёжности при отказе питания почти никакой.

Некомпетентен.

> Это самый верный способ напороться на глюк

Всегда есть шанс напороться на глюк.

> Потеря по производительности отнюдь не маленькая.

По моему опыту, просадка производительности записи в 90% случаев не смертельна.

> А raid на домашней машине, IMHO, нафиг не нужен. Ибо программный мало что меняет

Почему?

Вот вылетает один винчестер. Выключаю комп и бреду в магазин за новым.

>По моему опыту, просадка производительности записи в 90% случаев не смертельна.

С той же самой вероятностью в ordered-режиме нужные данные уже успеют записаться на диск до сбоя :D

> > А raid на домашней машине, IMHO, нафиг не нужен. Ибо программный
> > мало что меняет

> Почему?

Пропало питание -- ФС все равно запорота.

> Вот вылетает один винчестер. Выключаю комп и бреду в магазин за новым.

Во-первых, порча диска -- далеко не единственная причина, по которой может
пострадать ФС (см. изначальный вопрос).

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

Другое дело сервер. Такая роскошь, как простой, непозволительна. Потому
запасные диски куплены заранее. Сбойный диск сразу меняют на новый, и
юзвери даже ничего не замечают. Отключение электричества -- не проблема,
есть бесперебойник.

yes, ext3 sucks by design. (C) A. Morton

> Всегда есть шанс напороться на глюк.

Журналирование данных -- это один сплошной глюк (сходите, что ли, по ссылке,
почитайте, из-за чего это так).

> По моему опыту, просадка производительности записи в 90% случаев не смертельна.

Да что Вы говорите? http://lkml.org/lkml/2007/1/7/18

>>> А raid на домашней машине, IMHO, нафиг не нужен. Ибо программный > > мало что меняет

>> Почему?

> Пропало питание -- ФС все равно запорота.

Ну как-бы можно и дома бесперебойничек поставить. Можно маленький, что-бы пять минут подержал, скачки сгладить, и при падении дать остановить систему.

А если умерли домашние фотографии, то это не кино с музыкой, это не скачаешь. Могут и другие ценные или редкодоступные вещи быть. То есть, по сути здесь raid становится разновидностью бекапа.

А вот, кстати, что до этого было про работу с журналом на ФС смонтированной ro? Что тогда означает это ro?

По поводу NTFS - может это и плохая ФС, но на самом деле за все время пользования ею (несколько лет) она у меня ни разу не падала, и при зависании венды всегда смело жал "ресет".

Так что, походу, ReiserFS - самая надежная ФС? Других альтернатив нет? (не считая ИБП :-) )

А журнал в ext3, как я понимаю, нужен лишь для того, чтобы система быстрее поняла, что в ней потеряно? :-) Удобно, конечно, не нужно пять минут нервно курить в ожидании приговора. Но фактически толку от этого мало.

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

Про журналирование

> А журнал в ext3, как я понимаю, нужен лишь для того, чтобы система быстрее поняла,
> что в ней потеряно? :-)

Не только у ext3. У любой журналируемой ФС (в том числе и NTFS).

> Удобно, конечно, не нужно пять минут нервно курить в ожидании приговора.

> Но фактически толку от этого мало.

Толк есть, кончено. Структура самой ФС не нарушается. То есть,
если с файлом A/B/C не производилось никаких операций, то его
гарантированно можно "добыть" после сбоя _без_ fsck. Что не так
для ФС без журналирования. Например, директория A/B может быть "запорчена"
из-за того, что в момент сбоя создавался файл A/B/foo.

> А потом когда-нибудь диск будет синхронизирован с изменениями
> в кэше. Правильно?

Правильно. Любая вменяемая ОС делает так (если только вручную не отключить
кеширование). Даже m$ window$.

> Волнует такой вопрос: а когда же это произойдет,

1. Когда программа, работающая с файлом, попросит ОС записать на диск те
куски файла, которые находятся в кеше (fsync(), fdatasync(), msync()).
К сожалению, далеко не все программы делают это правильно.
2. Когда ядро решит освободить память, используемую под кеш, для какой-либо
другой цели, например, "отдать" ее какому-нибудь процессу.
3. Перед отмонтированием ФС.

> и произойдет ли это само по себе до того, как я выключу или перезагружу
> комп?

Не обязательно (кстати, это касается всех ОС).

> И может быть имеет смысл поправить какие-то настройки, чтобы синхронизация
> диска с кэшом происходила почаще?

Если по уму, то нужно исправить софтину, которая не делает вовремя fsync().
Но если Вы так настаиваете, такие настройки есть.

/proc/sys/vm/dirty_writeback_centisecs
/proc/sys/vm/dirty_expire_centisecs
/proc/sys/vm/dirty_ratio
/proc/sys/vm/dirty_background_ratio

Читайте документацию и уменьшайте. Производительность, конечно, тоже
будет падать.

> Ну как-бы можно и дома бесперебойничек поставить.

Так я ж и говорю -- не жалейте заварки.

> А если умерли домашние фотографии, то это не кино с музыкой, это не
> скачаешь. Могут и другие ценные или редкодоступные вещи быть. То есть, по
> сути здесь raid становится разновидностью бекапа.

Не становится. От случайного rm /тот/ценный/файл не спасает. От Oops'ов
тоже не спасает. И опять же -- народ заварку зажимает :).

> А вот, кстати, что до этого было про работу с журналом на ФС смонтированной ro?

fs/ext3/super.c

2100         really_read_only = bdev_read_only(sb->s_bdev);
2101
2102         /*
2103          * Are we loading a blank journal or performing recovery after a
2104          * crash?  For recovery, we need to check in advance whether we
2105          * can get read-write access to the device.
2106          */
2107
2108         if (EXT3_HAS_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER)) {
2109                 if (sb->s_flags & MS_RDONLY) {
2110                         printk(KERN_INFO "EXT3-fs: INFO: recovery "
2111                                         "required on readonly filesystem.\n");
2112                         if (really_read_only) {
2113                                 printk(KERN_ERR "EXT3-fs: write access "
2114                                         "unavailable, cannot proceed.\n");
2115                                 return -EROFS;
2116                         }
2117                         printk (KERN_INFO "EXT3-fs: write access will "
2118                                         "be enabled during recovery.\n");
2119                 }
2120         }

> Что тогда означает это ro?

Что-то вроде "чуть-чуть беременная".

> KERN_INFO "EXT3-fs: write access will be enabled during recovery

Это означает что оно при рекавери будет что-то писать или при нормальной эксплуатации тоже вносить какие-то изменения?

> А если умерли домашние фотографии, то это не кино с музыкой, это не > скачаешь. Могут и другие ценные или редкодоступные вещи быть.

Вот в том-то и фигня, что умерли фотки. В один прекрасный момент я просто обнаружил, что их нет. Куда они делись - неизвестно. Но они точно были. И это уже не первый случай, когда что-то куда-то исчезает. Раньше я грешил на себя, мол, сам наверное нечаянно удалил. Но теперь я точно уверен, что не мог этого удалить. Но их нет! Это не может не огорчать. И "упс" мне никак не прибавит уверенности в том, что ничего никуда не пропадет. Поэтому хочется более надежную ФС.

Так что, люди, все-таки посоветуете? ext3 или ReiserFS ?

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

А само по себе, по волшебству, ничего не исчезает.

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

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

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

> Но для меня является непреемлимым тот факт, что могут попортиться данные
> только потому, что они лежали в одном каталоге.

Не попортятся, а будут недоступны до fsck. Это две большие разницы. (C)
Даже если fsck не исправит директорию (что бывает довольно редко),
неповрежденные файлы будут в lost+found.

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

Есть такой анекдот.
Идут новый русский с дочкой по Парижу. Видят -- художник пейзаж пишет.
Новый русский: "Глянь, Машенька, как дядя без Polaroid'а мучится."

Даже если такая сверка понадобится, то делается она просто:

rsync -avH --delete --dry-run /path/to/backup/ /path/to/original/

(главное -- не забыть --dry-run).

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

Так не бывает. Как минимум, fsck должен был грязно ругнуться.

> И это уже не первый случай, когда что-то куда-то исчезает.
> Раньше я грешил на себя,

И это правильно. Есть три способа довести ext2 до такого состояния:

1. Долго и упорно (скажем, месяц -- другой) работать с ФС, несмотря
на ругань fsck.
2. (разновидность 1) Вовсе отключить проверку ФС.
3. Издевательство над железом и ядром: разгон, левые патчи "для повышения
интерактивности", "оптимизация" путем компиляции с -O3.

Все они относятся к категории "сам себе злобный Буратино".

> Но теперь я точно уверен, что не мог этого удалить.

Ага, конечно. Их стер Дедушка Мороз.

> Поэтому хочется более надежную ФС.
> Так что, люди, все-таки посоветуете? ext3 или ReiserFS ?

Ни одна из них не превосходит ext2 по надежности. По времени восстановления
от сбоя -- да, несомненно. Но не по надежности.

>Так не бывает. Как минимум, fsck должен был грязно ругнуться.

Кстати, по поводу недавней моей ругани по поводу потери торрент-сессий в XFS. Из 76 сессий раздача шла едва ли на десятке. Но занулились _все_ файлы соответствующего каталога...

> Так не бывает. Как минимум, fsck должен был грязно ругнуться.

Ругался, что-то там автоматически исправлял - и что? Фотки просто исчезли.

> Есть три способа довести ext2 до такого состояния

И ни к одному из них я не прибегал.

> Ага, конечно. Их стер Дедушка Мороз.

Я пока еще в своем уме.

> Кстати, по поводу недавней моей ругани по поводу потери торрент-сессий в XFS.
> Из 76 сессий раздача шла едва ли на десятке.

[пошел в google посмотреть кто такой торрент]
[вернулся]

"Раздача" -- это доступ на чтение или чтение/запись?

> Но занулились _все_ файлы соответствующего каталога...

Что такое "занулились" (ясно только, что как-то испортились, но что именно
произошло)?

> Ругался, что-то там автоматически исправлял - и что?

в lost+found есть что-нибудь?

> Фотки просто исчезли.

fsck запрашивает подтверждение для всех операций, так или иначе связанных
с потерей данных. Либо вываливается с ошибкой, если был запущен в
неинтерактивном режиме.

Чтоб что-нибудь "исчезло", нужно основательно запороть ФС. Либо вручную,
(dd if=/dev/zero of=/dev/sda), либо достаточно долго использовать ФС с
неисправленными ошибками (то есть, fsck не смог автоматически починить
ФС, а ее взяли и насильно подмонтировали, и так *надцать раз)

> Я пока еще в своем уме.

Человеку свойственно ошибаться и забывать. Даже если он в своем уме.

> fsck запрашивает подтверждение для всех операций

Запрашивал. Но если б я хоть что-то понимал из того, что он меня спрашивал. Так что я положился на него и отвечал Y. Может он спрашивал, не хочу ли я удалить свои фотки? :-)