[наброс][файловые системы][надёжность] #Ext4 подвела…

Надо было использовать reiserfs.

>> При отрубании питания

...ни одна ФС не может гарантировать сохранности данных. Надо было монтировать с data=journal, если часто электричество кончается.

Надо было использовать ext3

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

Нелёгкая судьбина...

>...ни одна ФС не может гарантировать сохранности данных

Вот только за много лет практики с reiserfs таких сбоев не было. Понятно, что возможно, просто везло. Но осадочек — остаётся.

Надо было монтировать с data=journal, если часто электричество кончается.

В том-то и дело, что reiserfs прекрасно работал с частыми зависами. Не по электричеству — у меня машина как-то несколько месяцев работала с бэдблоками на системных разделах, так что вылетала до нескольких раз в день и ресетилась жёстко потом. Так вот, в этих условиях reiserfs не дал ни одного серьёзного сбоя.

А в этом случае, наоборот, с питанием всё ок, это первый отказ у хостера за последние лет пять, наверное. Но машина посыпалась сразу.

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

>При отрубании питания у хостера

Странно, что у хостера нет резервного питания.

>Надо было использовать ext3

Спасибо, не надо. Вот она у меня сыпалась многократно. Вплоть до полной потери целиком раздела «на ровном месте», без всякого вырубания питания и т.п. :) Был такой случай — прихожу на работу, а сервер висит. То, что в памяти осело — ещё работает, а диск недоступен. После перезапуска оказалось, что раздел починке не поддаётся. Пришлось делать полный формат и переход на reiserfs :)

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

Про закон подлости слышал? Вот это оно.

>Странно, что у хостера нет резервного питания.

«Сегодня, 12.07.2011г. в Дата-Центре «Агава-Cевер» возникли проблемы с источником бесперебойного питания. Наши технические специалисты в данный момент делают все возможное для возобновления предоставления услуг в кратчайшие сроки».

:)

Оживили-то они всё, действительно, относительно быстро, но /var у меня осыпался… Это на одном сервере. Второй даже не завёлся. Но, поскольку он менее важен, разбираться с ним буду позже.

>Про закон подлости слышал? Вот это оно.

Ну да, оно. Потому и уточняю в сабжекте, что наброс :)

Ещё ext4 почему-то очень долго чинится. Минут 20 уже на разделе в 30Гб на SAS-винте. Под reiserfs даже rebuild-tree быстрее делался :)

Что меня ещё смущает, так это невероятно многочисленные:
«has 1 multiply-claimed block(s), shared with 6 file(s)»

Это что, FAT-like cross chains какие-нибудь? Такое, разве, в современных FS бывает? Или это что-то другое обозначает? :)

Будь мужиком, форматни /var в ntfs!

Проблемы с питанием имею очень часто, ничего не валится... тьфу, тьфу...

>Ext4 подвела
я один не удивляюсь?

PS: ext4 еще сырая. если вы не готовы ежемесячно/-недельно тащить патчи в своё ядро, причем вплоть до тех, что еще не приняли в mainline - ставить её на серьезное оборудование не стоит...

>ext4 еще сырая. если вы не готовы ежемесячно/-недельно тащить патчи в своё ядро

Да уже несколько лет использую её в целом и больше года — на продакшне. На упавшем сейчас сервере она полтора года простояла без нареканий и «ежемесячных патчей» :) Не было бы сбоя с питанием — и дальше бы работала.

Кстати, что тема делает в general?
В толксы же! Вопроса я тут никакого не вижу. :3

>Кстати, что тема делает в general?

Странно. Мне казалось, что я её именно в talks открывал. Или ошибся, или переместили :)

e2fsck уже полтора часа работает. Интересно, долго ещё?

>Оживили-то они всё, действительно, относительно быстро, но /var у меня осыпался… Это на одном сервере. Второй даже не завёлся. Но, поскольку он менее важен, разбираться с ним буду позже.

Да, печальная история...

>Надо было использовать reiserfs.

Опередил!

> ни одна ФС не может гарантировать сохранности данных.

ZFS?

> PS: ext4 еще сырая.

использовать etx2?

>использовать etx2?

А почему не на ext? :)

> А почему не на ext? :)

Оно наврено просто не соберется

надо было использовать ext2 или, в крайнем случае, ext3

HAMMER!

ext2 лишена журнала так что не катит. ext4 же отметилась кучей эпик фейлов, причем именно после включения в ядро.

не в дизайне ли проблема?

Возможно. Причем после включения в ядро разработчики потребовали от Линуса внесения именно тех изменений в общую архитектуру ядра из-за необходимости которых в ядро не включили в свое время Рейзер4

Но в данном случае проблема все же в агрессивном кешировании ext4 а не в vfs

>ext4 еще сырая
в centos6 дефолт, ибо в rhel6 дефолт =)

> Но в данном случае проблема все же в агрессивном кешировании ext4 а не в vfs

А как вообще может из-за кэширования падать? Или подсистемы ядра настолько назависимы (unix way), что они ничего друг другу не могут обещать

К.О. вещает, что надо делать бекапы.

>К.О. вещает, что надо делать бекапы.

Они, как бы есть, кэп. Но как они предотвратят падение ФС? :)

Какие-то ужасы вы все рассказываете. За 7 лет использования ext2-3-4 у меня проблемы были только на проблемном железе.

>у меня проблемы были только на проблемном железе.

Ну так о чём и вопрос :) Сабжевый случай проходит по категории «проблемного железа» :D

has 1 multiply-claimed block(s), shared with 6 file(s)

похоже на дедупликацию данных, ты радоваться должен что места кучу сэкономил :)

в совершенно статических файлах, которые никем не трогались и не менялись

А есть вероятность, что они не менялись после конвертации ext3 в ext4 (если таковая была, конечно)?

>А как вообще может из-за кэширования падать?

От кешировния записи могут пропасть данные на любой системе кроме системы с журналированием данных а журналирование данных очень медленная операция под которую лучше выделять отдельный винт

>А есть вероятность, что они не менялись после конвертации ext3 в ext4 (если таковая была, конечно)?

Не было конвертации, раздел от рождения под ext4.

смени хостера

Могу предложить гипотезу что данные двигались самой ФС с целью «предотвращения фрагментации».

Жесть:

File ... (inode #124955, mod time Tue Jul 12 10:05:01 2011) 
  has 9943 multiply-claimed block(s), shared with 9 file(s):
	... (inode #413947, mod time Tue Jul 12 10:05:01 2011)
	... (inode #413435, mod time Tue Jul 12 10:05:01 2011)
	... (inode #297851, mod time Tue Jul 12 10:05:01 2011)
	... (inode #296891, mod time Tue Jul 12 10:05:01 2011)
	??? (inode #295755, mod time Tue Jul 12 10:05:01 2011)
	... (inode #295595, mod time Tue Jul 12 10:05:01 2011)
	??? (inode #236811, mod time Tue Jul 12 10:05:01 2011)
	... (inode #191755, mod time Tue Jul 12 10:05:01 2011)
	/lib/mysql/OPENX/ox_data_intermediate_ad.MYI (inode #140699, mod time Tue Jul 12 10:05:01 2011)

>смени хостера

Альтернативы? :)

а мне не верят, что ext4 - зло :3

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

ReiserFS, говоришь? Подыхал у меня.

Что умиляет — over9k ошибок в совершенно статических файлах, которые никем не трогались и не менялись…

У меня подобная хрень была на XFS.

P.S. Все файловые системы — говно, в плане надёжности. Только бэкапам теперь доверяю я.

Пора валить на перспективную инновационную фс из шындоус 8?

Вот читаю я твои истории «успеха» и думаю: вот ты рекламируешь reiser повсюду и везде: а сам-то ты понимаешь причины, почему она оказывается «устойчивее»? Ведь у нее, в общем-то, нет никаких механизмов, которые ей эту устойчивость обеспечивали бы: ни дополнительных контрольных сумм журнала, ни COW, ни журналирования данных (вроде бы), ничего, что могло бы давать ей априорно бОльшую надежность в сравнении с той же ext4. Посему я могу сделать вывод: на глючном железе поведение многих FS просто РАНДОМНОЕ, кому-то везет больше, кому-то меньше.

Кстати, утверждать, что reiser «надежнее» я бы не стал, по крайней мере без подсчета контрольных сумм всех файлов после каждого сбоя. А то может она просто по-тихому сливает твои данные в /dev/null, а ты наивно об этом не знаешь.