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 ошибок в совершенно статических файлах, которые никем не трогались и не менялись…

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

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

ups подключить религия не позволит?

zloy_linuxoid
()

Ну а что ты хотел? Ext4 — красноглазая поделка, reiserfs — результат серьезных научных исследований. Пруфы в интервью Шишкина.

fat_angel ★★★★★
()

Чем обусловлено нежелание использовать FreeBSD и ZFS?

iZEN ★★★★★
()

А не может быть что у фс в системной области полетело всё? Я так один раз спас выглядевшей почти мёртвой ext3, взяв копию суперблока откуда-то издали через fsck.ext -b. Потерялись только имена каталогов самого верхнего уровня (обнаружил как ни странно их в lost+found с цифровыми именами типа #49234324). Ниже уровнем 98% все файлов и каталогов выжило.

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

> Пруфы в интервью Шишкина.

Толсто. Шишкин к _reiserfs_ никакого отношения не имеет, только к reiser4

unanimous ★★★★★
()

Через 16 часов работы e2fsck решил я, что быстрее будет поднять всё из бэкапа. Чем сидеть ещё неизвестно сколько.

Не знаю, чем уж там он занимался, но до начала исправлений на диске было занято ~24Гб из 30, сейчас, после того, как я его тормознул — 25Мб из 30Гб… При этом данных с него копирутся заведомо больше.

Сейчас снимаю как то, что копируется, так и сам образ (надо было, конечно, с этого начинать — вперёд наука), потом переформатирую и разверну /var со stage1. Ну и world пересоберу. Благо /var/lib/portage/world живой (надо записать себе в книжечку, что его, на всякий случай, тоже стоит бэкапить — оказывается, полезно).

Вообще, походу /var нужно по нескольким разделам растаскивать. Жаль, что на этой машине не догадался сразу LVM поставить. Сейчас очень нереально по живому на него перевести. Явно нужно в отдельных разделах держать:
/var/lib
/var/www
/var/cache
/var/tmp
и /var — всё остальное
Да ещё и /var/lib/mysql полезно тоже на отдельном разделе держать как основной потребитель /var/lib :)

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

> Вообще, походу /var нужно по нескольким разделам растаскивать

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

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

>дада LVM рулит и педалит

Сейчас прикинул — у меня весь /dev/sda (SAS-диск) влезает на /dev/sdb (бэкапный SATA). Так что, походу, загружусь с live-dvd и отдам весь /dev/sda под LVM. Ну, минус своп и /boot.

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

>Когда растащишь, расскажи, какие размеры выбирал и почему

Оно ж сильно индивидуально. И от системы и даже от конкретного использования. У меня нужно гигов по 5 под
/var/lib/mysql,
/var/tmp и
/var/cache.

Под /var/log сейчас нужно тоже гигов 5, но это потому что я сбрасываю ежесуточно архивы логов после ротации на медленный бэкапный диск. Если хранить прямо на месте, то это сразу ещё гигов 10.

Ну и /var/www — это ещё гигабайт 10. Хотя там данные нужны в основном в R/O и потому могут, в принципе, храниться в других местах.

Оставшееся занимает относительно мало места, в пару гигов, или в те же гигов 5, чтобы с запасом, влезет.

Но я лучше возьму уже LVM :) А то на /home отдал в своё время весь остаток диска, 208Гб, а занято там только 21Гб сейчас. Думал, если что, просто со временем туда закидывать данные со /var (скажем, /var/lib/mysql переместить в /home/mysql), но разнесение по разделам должно сильно если не поднять надёжность, то хотя бы облегчить восстановление :) Если бы у меня была разбивка, то сейчас бы я, наверное, восстанавливал только /var/lib/mysql и /var/logs. Другие-то подкаталоги /var при обычной работе мало пишутся.

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

> > Вообще, походу /var нужно по нескольким разделам растаскивать

Когда растащишь, расскажи, какие размеры выбирал и почему - сам давно об этом

думаю, но пугает долгосрочная перспектива нехватки места на разделах.

Используй LVM и головняки с распределением места отпадут.

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

>Используй LVM и головняки с распределением места отпадут.

Правда, там могут полезть головняки с фрагментацией разделов, но это, безусловно, несравнимо меньшая головная боль :)

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

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

Данные. Но не нарушать же из-за этого целостность файловой системы


И давно целостность фс стала важнее, чем сохранность данных?

AnDoR ★★★★★
()

Сдаётся мне что ext здесь не при чем. Более вероятно, что хостер вовремя не заменил батарейку на RAID контролере.

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

>Правда, там могут полезть головняки с фрагментацией разделов, но это, безусловно, несравнимо меньшая головная боль :)

logical extent'ы можно вживую мигрировать ( pvmove ) , так что эта фрагментация вживую же и убирается :)

Единственный недостаток - pvmove соглашается перемещать экстенты только над другой phisical volume, т.е. для «дефрагментации» понадобится ещё один диск в той же volume group. Но можно сделать файл подходящего размера, объявить его блочным устройством (losetup) и переносить extent'ы через него (pvcreate , vgextend, pvmove, ...., pvmove, vgreduce, pvremove)

З.Ы. я бы своп создавал тоже в lvm, но дело вкуса :)

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

>З.Ы. я бы своп создавал тоже в lvm, но дело вкуса :)

Уже пришлось :) Сделал LVM, развернул систему, перенёс старые данные, и когда стал менять fstab на тему новых правил, увидел, что забыл отвести раздел под своп. Пришлось добавлять уже в LVM :)

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

Кстати, месяцев два компьютер с ext4 работал в режиме «каждые несколько часов - отключение питания» (сейчас проблема решена UPS-ом). Ни один файл не умер. Так, что случай топикстартера единственный.

Deleted
()
Ответ на: комментарий от MikeDM

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

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



Походу после этого сбоя питания у Агавы полетел далеко не мой единственный сервер :D Я с вечера ещё просил IP-KVM для airbase.ru/balancer.ru (тоже лёг, х.з. почему, может и не сбой питания, я ядро пару раз обновлял и не перезагружался — из-за этого могло не подняться), так только сейчас ответили, сказали, что очередь на KVM'ы такая, что никак сейчас предоставить не могут, зато предложили попробовать восстановить мне сервер своими силами :) Ну, пусть пробуют…

На сабжевом aviaport.ru было проще, там IP-KVM встроенный в сервер.

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

>> Данные. Но не нарушать же из-за этого целостность файловой системы

И давно целостность фс стала важнее, чем сохранность данных?


незаписанные на диск данные, лучше, чем записанные, но никто не гарантирует, что это то, что туда писали. пирожок с гамном заместо капусты не желаете? а что, не пустой ведь ;)

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

>> Данные. Но не нарушать же из-за этого целостность файловой системы

И давно целостность фс стала важнее, чем сохранность данных?

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

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

>>ext4 еще сырая

в centos6 дефолт, ибо в rhel6 дефолт =)

и что дальше? одно другому не мешает =)

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

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

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

>Не было бы сбоя с питанием — и дальше бы работала.
ну так без сбоев питания и другие FS неплохо работают и десятилетиями :)

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

Таки это показатель неудачного дизайна и низкого качества кода

DNA_Seq ★★☆☆☆
()

Гы. Ну, в общем, второй сервер тоже стал доступен. Что характерно — тоже проблемы на /var. Интересно то, что интенсивно записываемая база mysql, судя по всему, жива, а вот практически полный R/O mercurial репозиторий сдох (/var/mercurial).

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