Посоветуйте ФС на внешний диск (проблемный)

> закончились резервные запасы на бэд-блоки
Это если Offline_Uncorrectable больше 0.

И да, следить нужно не сколько за количеством (например, e2fsck с опцией -c при помощи badblocks пометит все бедблоки как неиспользуемые), а за его динамикой.

s/сколько //

а в чем фишка такого действия? Данных не жалко в принципе? Такому диску я бы ничего вообще доверять не стал.

Ну, к примеру, 10 фильмов перетащить. Если один - два не запишутся / прочитаются, то ничего страшного. На этом диске данные долго хранится не будут - только транспортировка. Просто нужно найти ФС понадежнее, вопрос производительности можно отбросить. Ваши предложения?

>превышен

В смысле, наоборот, ниже чем допустимый порог (там вроде в обратную сторону по стопроцентной шкале идёт отсчёт)? И вообще, есть же параметр WHEN_FAILED.

Да и не совсем понимаю, как файловая система должна исправить износ диска.

Сделать несколько одинаковых разделов и писать на них несколько копий фильмов. Надёжнее не придумать (а может есть такая функция в LVM?)

Не исправлять, а максимально предотвращать потерю данных

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

максимально предотвращать потерю данных

Этим свойством обладает ZFS. Она как раз создавалась для дешёвых и малонадёжных устройств. Но вам я её не советую.

Я бы reiserfs посоветовал, очень живучая.

>> Это если Offline_Uncorrectable больше 0.

Неправда. У меня и после этого росло количество перемещений.

>> а может есть такая функция в LVM?

Да.

почему не советуете использовать ZFS?

>Этим свойством обладает ZFS. Она как раз создавалась для дешёвых и малонадёжных устройств.

/me записал - сановское железо - говно.

Из xgu.ru :
преимущества:
"...использование продвинутых алгоритмов хэширования для повышения надёжности хранения"
почему не надо пользоваться:
«ZFS пока что нельзя линковать с ядром Linux, поэтому если использовать ZFS под Linux, то делать это можно при помощи FUSE. Понятно, что это не совсем то, что хотелось бы, но поэкспериментировать и познакомиться с ZFS можно»

Погуглив отдаю предпочтение в сторону ReiserFS (надеюсь фс от убийцы окончательно не убьет винчестер =))

живучая? если в ней метаданные накроются, то «костей» не соберешь, в отличие от той же ext2.

>> максимально предотвращать потерю данных

Этим свойством обладает ZFS

Да нет, при отсутствии избыточности она влет теряет данные при сбоях на винте. Как и другие.

>делать это можно при помощи FUSE. Понятно, что это не совсем то, что хотелось бы, но поэкспериментировать и познакомиться с ZFS можно"

Я пробовал, даже бенчмарки гонял. Работает, юзабельно, но требует некоторой настройки, для флешки/съёмного диска неприемлемо.

>ZFS

создавалась для дешёвых и малонадёжных устройств.

Вот это толщина. Записал новую фразу для троллинга.

Я бы посоветовал бы UFS+SoftUpdates

>Я бы посоветовал бы UFS+SoftUpdates

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

Пока думаю о ReiserFS. Больше советов не будет?

>ZFS

создавалась для дешёвых и малонадёжных устройств.

Вот это толщина.

Чего это толщина? Если у тебя пул дешёвых и малонадёжных устройств...

iZEN

Но вам я её не советую.

А выпендриться надо, особенно когда главного ЗФС-ненавистнега забанили :)

>> Больше советов не будет?

ext3

>Чего это толщина? Если у тебя пул дешёвых и малонадёжных устройств...

... я сделаю raid через mdadm, а потом уже буду думать, куда тут прикрутить zfs.

>Человек просил файлуху, способную перенести сбой, а не чудо, которое дохнет от каждого чиха. Читаем топик.

Это чудо, в отличии от EXT/2/3/4 и Райзера пережило тыщу падений.

>Это чудо, в отличии от EXT/2/3/4 и Райзера пережило тыщу падений.

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

>в отличии от EXT/2/3/4

А их даже тебе уронить не удалось, я так понял.

Это технический вопрос. Не троль тут.

> Вот это толщина.

Это бывший «эффективный» менеджер Sun Джонатан Шварц написал в своём блоге.

Записал новую фразу для троллинга.

Лучше дам ссылку: http://blogs.sun.com/jonathan/entry/not_a_flash_in_the

>написал в своём блоге.

Ну то есть они эту ФС по приколу сделали для кривых 5,25 флопаков. А тут некрофилы из BSD как накинутся..

Совсем недавно тема была:

http://www.linux.org.ru/forum/linux-install/5596275

Оффтоп: у Вас ник говорящий :)

Они сделали чудную ФС для кривых HDD, псевдоаппаратных RAID, шин данных, которые работают с ошибками, и для модулей памяти из помойки.

не для, а способным нормально работать на этом и облегчая жизнь в управлении всем этим барахлом. feel the difference ;)

> >Чего это толщина? Если у тебя пул дешёвых и малонадёжных устройств...

... я сделаю raid через mdadm, а потом уже буду думать, куда тут прикрутить zfs.

Изен, где там твой любимый пример по mdamd? :-)

> Сделать несколько одинаковых разделов и писать на них несколько копий фильмов. Надёжнее не придумать (а может есть такая функция в LVM?)

Лучше заюзать ZFS, причем FUSE для ТСа нормальный выбор, если производительность некритична. ZFS по умолчанию хранит несколько копий метаданных (до 3) в разных местах диска. Если есть желание, можно эту же фичу включить и для пользовательской данных установив свойство copies в 2 или 3.

>живучая? если в ней метаданные накроются, то «костей» не соберешь, в отличие от той же ext2.

Если метаданные накроются, я сделаю rebuild-tree и буду работать дальше.

В свое время был случай, когда система с рейзером на корне была запущена в виртуалке, образ диска которой хранился в файле и потому был частично закеширован. На хосте отвалилось питание. Пришлось аж десять минут ждать, пока rebuild-tree делается, какая незадача! Зато потом система нормально заработала. До сих пор работает.
// На хосте тоже рейзер был, так он вообще не жаловался. fsck автоматом все сделало.

всё значительно проще..

пишите файл с избыточностью, есть утилиты создающие коды коррекции

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

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

> Изен, где там твой любимый пример по mdamd? :-)

В закладках, конечно же: http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3272939

О! дважды с помощью rsync копировать. Наверное тогда проверит всё ли прошло, если он конечно md5 считает.

>> В закладках, конечно же

Любишь демонстрировать собственную некомпетентность?

>> жаль в линуксе нет способа записи (не знаю о таком) с непрерывной проверкой читаемости и корректности записанного блока данных.

Избыточный RAID же :) Только, очевидно, это ещё быстрее отправит диск на тот свет.

> Любишь демонстрировать собственную некомпетентность?

Это почему это, позвольте поинтересоваться?

Сходи по ссылке уже. Там ломается зеркальный рейд путём повреждения метаданных на нижележащем устройстве. Это что, означает проблемы в реализации рейда? :)

Это что, означает проблемы в реализации рейда?

ZFS эту проблему находит и отключает проблемный носитель. MDADM — нет и тупо считает, что всё в порядке, и выдаёт мусор на выходе. :))

Избыточный RAID же :)

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

ZFS эту проблему находит и отключает проблемный носитель.

То есть оно постоянно следит за состоянием нижележащего устройства? Зачем?

MDADM — нет и тупо считает, что всё в порядке, и выдаёт мусор на выходе. :))

И это логично. Предполагается, что администратор не является криворуким идиотом, который что-то пишет напрямую в underlying device, не отдавая себе отчёта в своих действиях. В случае же аппаратных проблем, мы получаем ошибку ввода/вывода, после чего массив становится degraded.

>То есть оно постоянно следит за состоянием нижележащего устройства? Зачем?

Чтобы скорость была ниже, очевидно же.

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

RAID5, к примеру, проверяет каждый записанный сектор. //К.О.