LINUX.ORG.RU
ФорумTalks

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


0

2
File ??? (inode #18051, mod time Fri Feb 18 03:03:58 2011) 
  has 1 multiply-claimed block(s), shared with 6 file(s):
	??? (inode #296979, mod time Fri Feb 18 03:03:58 2011)
	... (inode #295379, mod time Fri Feb 18 03:03:58 2011)
	/www/.maildir/new/1297987438.V803I40843M183636.aviaport (inode #264259, mod time Fri Feb 18 03:03:58 2011)
	??? (inode #83267, mod time Fri Feb 18 03:03:58 2011)
	??? (inode #62163, mod time Fri Feb 18 03:03:58 2011)
	??? (inode #16179, mod time Fri Feb 18 03:03:58 2011)
Clone multiply-claimed blocks? yes

Перехвалил я ext4. При отрубании питания у хостера вылетели тонны сбоев на /var. Конечно, случай пока единственный, но на reiserfs за несколько лет и многие десятки, если не сотни нештатных отрубаний таких потерь не было.

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

★★★★★

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

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

GotF ★★★★★ ()

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

xorik ★★★★★ ()
Ответ на: комментарий от GotF

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

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

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


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

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

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

KRoN73 ★★★★★ ()

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

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

Tigger ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от Tigger

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

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

:)

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от LongLiveUbuntu

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

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

KRoN73 ★★★★★ ()

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

KRoN73 ★★★★★ ()

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

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

KRoN73 ★★★★★ ()

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

anonymous ()

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

erfea ★★★★★ ()

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

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

xydo ★★ ()
Ответ на: комментарий от xydo

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

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

KRoN73 ★★★★★ ()

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

bsdfun ★★★★★ ()
Ответ на: комментарий от bsdfun

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

Tigger ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

namezys ★★★★ ()

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

zgen ★★★★★ ()
Ответ на: комментарий от namezys

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

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от namezys

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

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от DNA_Seq

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

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

namezys ★★★★ ()
Ответ на: комментарий от mi_estas

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

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

KRoN73 ★★★★★ ()

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

Zenom ★★★ ()
Ответ на: комментарий от Zenom

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

true_admin ★★★★★ ()

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

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

Darth_Revan ★★★★★ ()
Ответ на: комментарий от namezys

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

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

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от Darth_Revan

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

DNA_Seq ★★☆☆☆ ()

Жесть:

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)

KRoN73 ★★★★★ ()

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

megabaks ★★★★ ()

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

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

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


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

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

fang ()

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

Yareg ★★★ ()

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

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

unanimous ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.