URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 80930
[ Назад ]

Исходное сообщение
"ext3 -- сплошное разочарование"

Отправлено utandr , 27-Июн-08 07:48 
Здравствуйте!


Стояла себе, работала машинка.

/usr -- одна партиция, /usr/local -- другая партиция (на одном винте).

Заканчивается электропитание в здании, потом в ИБП. Машинка отключается.
После загрузки жалуется на проблемы с ФС /usr/ (/dev/sda3) и не может восстановиться.

Монтируется только в режиме read only.

Не то, чтобы я хотел вызвать спор между ntfs и ext3, но вспомнить, чтобы хотя бы один раз на какой-нибудь машине под Windows + NTFS было что-то подобное не могу. Читаю всякие маны, и вот узнаю, что "не плохо бы регулярно копировать образ партиций по расписанию..", типа на всякий случай.. (?!).

Дело в том, что /usr -- это же не какой-нибудь /var или /home, туда вообще ничего не пишется. А тут при монтировании какие-то проблемы.

Может, это я идиот? Может, есть какие-нибудь волшебные ключики fsck.ext3, которые бы восстановили самостоятельно весь раздел?
Или, может быть, есть что-нибудь еще замечательно, что восстановило бы все без "восстановлений inode путем debugfs при таких-то условиях"?


Содержание

Сообщения в этом обсуждении
"ext3 -- сплошное разочарование"
Отправлено angra , 27-Июн-08 08:07 
>Может, это я идиот?

Заметьте, не я это сказал :)

Вот у меня ни разу не было неисправимых проблем с ext3, даже при сбоях питания. После сбоя fsck иногда находил несколько orphaned inode, оставшихся от временных или удаленных файлов, и прекрасно сам их фиксил.
Зато несколько раз видел смерть(причем полную, никакие chkdisk не спасали) ntfs без всяких сбоев питания, более того, после корректного завершения работы.
И что это доказывает? Ровным счетом ничего, у каждого личный опыт с fs и к объективности отношения он не имеет. А бэкап всегда нужен, причем на другой носитель, ведь в один "прекрасный" день может умереть винчестер или даже raid и не будет никакой разницы что за fs там стояла.

Насчет ключиков, попробуйте -y или -p. Однако при серьезном сбое их действительно может не хватить.


"ext3 -- сплошное разочарование"
Отправлено utandr , 27-Июн-08 08:26 
>Может, это я идиот?
>Заметьте, не я это сказал :)

Ангра, Вы удержаться не смогли.. Понятное дело :)

>Насчет ключиков, попробуйте -y или -p. Однако при серьезном сбое их действительно
>может не хватить.

Их, конечно, и не хватает.

Вот 350 компьютеров под разными компьютерами с NTFS -- и ни одного сбоя. А тут -- бац, и есть сбои после отключения электропитания (хотя не виртуальных серверов под Linux всего 2 -- один, действительно, живет уже вот лет 5 без какого-либо мониторинга).


Странное дело: я подключаю упавший раздел в ro, копирую с него файлы на другую партицию другого жесткого диска, и получаю ошибки fsck уже на нем. Это, вообще, как такое может быть?

В качестве копирования использовал cp -r /usr/* /home/_backup/usr


"ext3 -- сплошное разочарование"
Отправлено Gennadi , 27-Июн-08 15:31 
>
>В качестве копирования использовал cp -r /usr/* /home/_backup/usr

Ну, что ж вы такое делаете? Вы же таким копированием все права на файлы изменяете!!!

Лучше так:

cp -a /usr /home/_backup


"НЕПОДКЛЮЧЕННЫЙ SWAP??"
Отправлено utandr , 27-Июн-08 09:27 
Узнал, что в fsck "segmentation fault" возникает при неподключенном swap'е (?!)
http://www.monkey.org/openbsd/archive/misc/0107/msg00056.html

Кажется, раньше в /etc/fstab было что-то вроде uuid=.... для какого-то раздела (может, как раз свопа). Я его удалил ранее (в смысле, запись об uuid, но "обычную" запись о свопе оставил, и её вижу).


Никто не может объяснить, как быть? :)

Ведь swap подключается самым последним из разделов.

Сейчас в repair filesystem делаю:
swapon /dev/sda8 (у меня тут swap)
fsck.ext3 /dev/sdb3 (странная партиция, которая не подключается)

Но, все-равно, segmentation fault..

Учитывая, что упала резервная партиция (т.е. упал, по сути, бэкап),
я легко отделался, и заново пересоздал партицию mkfs.ext3 /dev/sdb3, но уже записав, где хранятся суперблоки.

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


Вопросы:
1. Как избежать проблем с винтом при отключении электропитания (может быть всякое, и ИБП не спасут. В конце-концов, при отключении света файловая система не должна терять целостности, могут не записываться изменения в файлах, но _целостность_ из-за электричества??). Кстати, упала партиция, на которую 100% ничего не писалось в тот момент времени.
2. Как загружаться, даже если возникают ошибки на каком-нибудь из разделов (например, плевать я хотел на проблемы в резервных винтах: все основное выжило, и слава Богу, загрузись и дай ssh доступ к машине)?
3. Как создавать на лету образ жесткого диска целиком, вместе с партициями на нем, на другой жесткий диск (т.е. как "на лету" копировать винт целиком)?


"НЕПОДКЛЮЧЕННЫЙ SWAP??"
Отправлено angra , 27-Июн-08 10:24 
>Узнал, что в fsck "segmentation fault" возникает при неподключенном swap'е (?!)
>http://www.monkey.org/openbsd/archive/misc/0107/msg00056.html

В том топике скорее от недостатка виртуальной памяти. У меня есть машина вообще без swap и никаких сегфолтов

>И все-таки, это просто полная мудосрань за момент отключения электричества в _журналируемой
>системе_ без _физических проблем_ жесткого диска лечь партиции до такого уровня,
>что нужно было все переделывать.

Согласен. Но опять таки я видел смерть ntfs после корректного завершения работы, согласитесь это куда большая "мудосрань".
На всякий случай проверьте на бэды и прогоните тест смарта.


>1. Как избежать проблем с винтом при отключении электропитания (может быть всякое,
>и ИБП не спасут. В конце-концов, при отключении света файловая система
>не должна терять целостности, могут не записываться изменения в файлах, но
>_целостность_ из-за электричества??). Кстати, упала партиция, на которую 100% ничего не
>писалось в тот момент времени.

Можно держать раздел в read-only, если это бэкап. Вот только в первом посте вы говорили про /usr, хотя и его при желании можно перевести в ro
>2. Как загружаться, даже если возникают ошибки на каком-нибудь из разделов (например,
>плевать я хотел на проблемы в резервных винтах: все основное выжило,
>и слава Богу, загрузись и дай ssh доступ к машине)?

Скопировать все необходимое на рутовый раздел. Например для ssh надо временно отмонтировать /usr предварительно скопировав все необходимые для работы ssh бинари и либы. Затем переместить их в каталог /usr, сохранив структуру. В результате в случае сбоя будут использоваться файлы с /, а если сбоя не произойдет то монтирование перекроет /usr. Список необходимых файлов можно узнать у пакетного менеджера и написать небольшой скрипт для их копирования.
>3. Как создавать на лету образ жесткого диска целиком, вместе с партициями
>на нем, на другой жесткий диск (т.е. как "на лету" копировать
>винт целиком)?

На лету(смонтированные в rw разделы) наверное не стоит, может фигня получится. А так вообще dd или partimage в зависимости от цели. Для бекапа/переноса лучше последнее.



"НЕПОДКЛЮЧЕННЫЙ SWAP??"
Отправлено aistpsk , 27-Июн-08 13:28 
может озу просто глючит ?

"НЕПОДКЛЮЧЕННЫЙ SWAP??"
Отправлено Utandr , 27-Июн-08 13:35 
>может озу просто глючит ?

Очень интересная версия, о таком не думал.
Только не понятно, как связано с отключением электропитания.

Я выяснил, у меня по итогам упал /usr (он был резервным). И, я думал, хрен с ним, что так.
Скопировал с настоящего /usr, но система перестала загружаться. проверка логов показала, что файла на основном /usr тоже битые (fsck -f показывает, что файловая система в прекрасном состоянии). Везде ext3...:(

Оснований валить на винт у меня нет (хотя еще детально посмотрю).
Кстати, как читать s.m.a.r.t. HDD из-под Linux kernel 2.6.x?
Как лучше тестить hdd? Можно ли это делать "на лету" (работает система год, потом стали появляться ошибки, чтобы о них узнавать еще до падения)?


"НЕПОДКЛЮЧЕННЫЙ SWAP??"
Отправлено Gennadi , 27-Июн-08 15:41 
>[оверквотинг удален]
>
>Очень интересная версия, о таком не думал.
>Только не понятно, как связано с отключением электропитания.
>
>Я выяснил, у меня по итогам упал /usr (он был резервным). И,
>я думал, хрен с ним, что так.
>Скопировал с настоящего /usr, но система перестала загружаться. проверка логов показала, что
>файла на основном /usr тоже битые (fsck -f показывает, что файловая
>система в прекрасном состоянии). Везде ext3...:(
>

Вот-вот "Скопировал".... и все права на файлы поменялись на root:root! Это же не винда...

man cp

-a, --archive
     same as -dpR


"НЕПОДКЛЮЧЕННЫЙ SWAP??"
Отправлено Utandr , 27-Июн-08 16:09 
Здравствуйте!

А, не, чукча умный, чукча харашо капиравал.

Только файлы битые оказались, однако -- в теле файлов были всякие посторонные символы, однако..

>[оверквотинг удален]
>>система в прекрасном состоянии). Везде ext3...:(
>>
>
>Вот-вот "Скопировал".... и все права на файлы поменялись на root:root! Это же
>не винда...
>
>man cp
>
> -a, --archive
>     same as -dpR


"reboot error --- umount /dev/sda3: device busy"
Отправлено Utandr , 27-Июн-08 13:41 
Уважаемый Олл и Ангра в частности!

Во время перезагрузки встречаю такое: umount /dev/sda3: device busy

О чем бы это могло говорить?..

В однопользовательском режиме отмонтировать партицию тоже не получается (монтируется нормально, но не демонтируется).


"reboot error --- umount /dev/sda3: device busy"
Отправлено zlogr , 27-Июн-08 13:55 
>Уважаемый Олл и Ангра в частности!
>
>Во время перезагрузки встречаю такое: umount /dev/sda3: device busy
>
>О чем бы это могло говорить?..
>
>В однопользовательском режиме отмонтировать партицию тоже не получается (монтируется нормально, но не
>демонтируется).

man fuser
fuser -amv /dev/sda3


"reboot error --- umount /dev/sda3: device busy"
Отправлено aistpsk , 27-Июн-08 14:17 
smartctl --all -d ata /dev/sda
smartctl --all /dev/hda
ошибки работы с диском смотри в /var/log/messages или /var/log/debug

варианты :
cat /var/log/messages |grep "attempt to access beyond end of device"
cat /var/log/messages |grep  "unable to read inode block"
cat /var/log/messages |grep  "error (device ide"
cat /var/log/messages |grep "megaraid: invalid"
cat /var/log/messages.* |grep "attempt to access beyond end of device"
cat /var/log/messages.* |grep  "unable to read inode block"
cat /var/log/messages.* |grep  "error (device ide"
cat /var/log/messages.* |grep "megaraid: invalid"



"Может, дело в драйверах контроллера?"
Отправлено Utandr , 27-Июн-08 16:14 
У меня скромное предположение: может, какие-то процедуры плохо работают именно для этого контроллера (i915G /SATAII )?

Ведь драйверов же я никаких не ставил -- все само должно было найтись, и нашлось.

У меня другой сервер уже лет 5 работает, и что только с ним не случалось: и "падал" БП, и работал в +40 со сломанным кондиционером в закрытом помещении, пережил три смены места, потеря питания случалась многократно (более 20 раз), но работает стабильно до сих пор..