Что-то при любых аварийных перезагрузках рушится glibc
seyko 11 июня, 2007 - 19:39
В последнее время заметил, что при аварийных перезагрузках часто портится glibc. При этом система не то чтобы совсем не загружается. Нет. Грузится почти наверняка. Но появляются глюки. Наиболее заметно это по пропаданию рамочек в Midnight Commander. Остальное тоже начинает глючить, но уже по-разному, трудно уловить закономерность. Например однажды гостевая ОС в VirtualBox перестала получать IP по DHCP. Переустановка glibc (из бинарников) решает проблему.
glibc-2.5-r3, Linux-2.6.18. Никто с таким поведением не встерчался?
»
- Для комментирования войдите или зарегистрируйтесь
у меня
у меня несколько раз оффлайн был по питанию, но невстречал никаких глюков
Видимо
Видимо проблема в hdd, надо винт по тестировать.
Винт нормальный
Протестировал винт, плохих блоков нет. Раньше перегружался по питанию, недавно была проблема с ядром -- неправильный патч для vm86 и ddcxinfo-knoppix в загрузочных скриптах вызывал панику и перезагрузку. Так результат возник такой же.
Если у других подобного не наблюдается, то предположение такое: перезагрузка при идущей записи на винт сбивает мозги у винта или просто дергает головку и запись идет не туда, куда ей следовало.
Соответственно, если перезагрузка идет при отсутствии записи на винт (ничего не делаем). то глюков не обнаружим.
Возможно, что глюк завязан на версию фирмвари винта или вообще на на конкретную модель винта.
Помню давным-давно специально для работы с Linux один из производителей винтов (Maxtor?) выпускал новую фирмварь, которую надо было залить в винт. Иначе винт как-то не так писал (что-то сбивалось у него в механизме кэширования). Проблема была именно с Linux (особенностью его драйвера), в виндах все работало нормально.
Однако возможно, что так ведут себя многие винты. Где гарантия, что у винта прервется запись, прежде чем дернется (или начнет перемещаться) головка?
PS: Как я понимаю, от такого может защитить только ZFS? Или ext4 или reiser4 тоже имеют средства защиты? Относительно reiser4 читал, что в качестве модуля вместо шифрации можно применить модуль CRC и тогда при чтении неверная информация будет обнаружена.
PPS: Относительно ZFS: было сообщение в интернете от чела, который на соляре перешел на ZFS и быстро обнаружил проблему с кабелем: доволно редко запись происходила с ошибками, но без ZFS он их в основном даже не замечал.
Кстати
У меня файловая система на корне Ext2/Ext3 (глюки были при обоих системах) и стоит опция "продолжить при ошибках" (Errors behavior: Continue) Может в этом дело? Ведь по идее винт должен сам обнаруживать записанные в сбойном режиме сектора (у него тоже CRC пишется)
А как ZFS может
А как ZFS может от этого защитить если, как сам говоришь, проблема вероятно в логике винта. Ну допустим просто удастся снизить частоту таких сбоев.
PS: а ZFS работает на линухе, может имелось ввиду XFS?...
PS: я использую XFS (совместно с LVM). Как-то было что в течении недели в доме электрики свет отрубали без предупреждения. Система почти всегда была под какой-нибудь загрузкой (компиляция, просто работа), но данные ни разу не по рушились.
я обычно
я обычно использую комбинацию LVM2 & ReiserFS так или поверх аппаратного рейда...
при ребуте по питанию проблем не разу не возникало...
ЗЫ из за стройки рядом они какой то период назад случались регулярно... Тока один раз пришлось фс чекать и все =)
_________________
Gentoo GNU/Linux 2.6.21 GCC 4.1.2 Dual Xeon
Working on Gentoo for iPAQ hx4700 :-)
reiser3 ?
Просто ради статистики...
XFS
Да, проблемы с glibc на ext2/ext3 -- хороший повод попробовать другие FS. Проблема скорее всего в логике размещения новых файлов или inode относительно старых данных.
А ZFS не работает пока в Linux (но будет ведь когда-нибудь). Исправлять ошибки ZFS сам по-себе не сможет (для этого он полагается на RAID5), зато хоть сообщать о них будет (обнаруживать).
В свое время долго занимался ArVid для Linux. Вот бы прикрутить куда-нибудь его ReedSolomon. Под i386 код был хорошо оптимизирован.
А в чем
А в чем заключается ReedSolomon?
Кстати, буквально сегодня на опернет ньюс про сверхнадежныу ФС - http://www.opennet.ru/opennews/art.shtml?num=11086
Хотя там опять п*шь про ZFS развели... это чё прямь "мегаФС далекого будущего", чего столько шума то о ней?
ReesSolomon
ReedSolomon -- он не только обнаруживает ошибки, он позволяет исправлять ошибки до определнного уровня (количества изменнений). Он используется фирмварью винтов (для коррекции ошибок), в RAID 5, и тд...
А про FS для БТР (Btrfs) -- прочитал с удовольствием и собираюсь отслеживать разработку. Для CRC данных (и метаданных) он использует CRYPTO_MANAGER, который оказывается уже есть в ядре. По идее товарищ дипломник хочет реализовать все то, что и мне хочется. Там и сравнение XFS с ext3 есть. И какие-то неиспользуемые мной опции монтирования ext3 (-o barrier=1), чтоб кэш сбрасывался на диск.
А про ZFS: уж не знаю как именно, но в System Rescue CD 0.3.6 на основе Gentoo (LOR от сегоднешнего числа) реализована beta-поддрежка ZFS (fuse-ZFS ???).
Про ZFS under fuse
Про ZFS under fuse есть слухи в Нете, но не проверял, да и не хочеться :)
Btrfs: Ого, с такими-то возможностями такие красивые бенчмарки, даж не вериться :) Будем надеяться что так и будет. Хотя для полноты картины не хватает отчёта по загрузке проца и среднего расхода дискового пространства на ведения всего этого журнала и контрольных сумм.
Буду рад увидеть Btrfs в ядре линукса :)
файловая
файловая система у тебя какая там стоит?
проблема у тебя в ней =)
_________________
Gentoo GNU/Linux 2.6.21 GCC 4.1.2 Dual Xeon
Working on Gentoo for iPAQ hx4700 :-)
А какая FS наиболее устойчива для сбоев по питанию?
Создалось впечатление, что ext2/ext3 пишет слишком близко к уже давно существующим данным (например размещает новые inode рядом со старыми данными). Судя по другим ответам, reiser3 -- возможный кандидат в лидеры?
reiserfs не лидер
К сожалению обстановка в мире reiserfs сильно изменилась и не пользу последнего. Почитайте: http://bugs.gentoo.org/show_bug.cgi?id=179796 и ссылочки оттуда... В общем, теперь, я бы не советовал (и сам больше не использую) reiserfs нигде кроме как в /usr/portage.
Наблюдаю
Наблюдаю похожую проблему на pc-роутерах, собранных на базе rhel. Самосборный минимальный дистрибутив, установленный на ide-flash. Очень часто, при сбоях в питании, портится /lib/libc-2.3.2.so При этом после включения система вообще не грузится, вываливается в сегфолт сразу после старта init. Помогает перезапись этого файла новым. В качестве корневой фс используем ext3.
А ядро какой версии?
Похоже, что ext2/ext3 имеет плохую карму для случая сбоя по питанию... То есть имеет склонность записывать в области, расположенные рядом с уже давно созданными данными. Например, располагает новые inode рядом со старыми даннми.
Re: А ядро какой версии?
Не соглашусь.
Сколько лет использовал ext2 - НИ РАЗУ не было сбоя файловой системы при аварийном отключении питания. Проверяется после сбоя долго - да, есть такое. Но не больше.
Причём местами момент сбоя достоверно попадал на операции чтения/записи.
Смотрите железо.
Смотрите железо
Так вот другие FS (типа ZFS) ловят ошибки железа. А ext2 -- не ловит. raid5, конечно, хорошо, только ведь и без него можно было бы ловить ошибки.
PS: пока поставил на ext3 полный лог (в том числе и данных) и запись метаданных только после данных
PPS: ext4, говорят, тоже extent-ы использует. Мож она и crc может (типа как описанная выше btrfs)? А то в sabayon грозятся на ext4 перейти (от reiser4 они отказались по причине многочисленных проблем-жалоб от пользователей)
рейзер4
рейзер4 задумывался как систему на плугинах, там что хош (теоритически) можно