Доброго времени !
Столкнулся с неприятностью :
Имею "домашний" сервачок (для своих эксперементов) на котором кртятся веб сервер , впн сервер , прокси сервер , фтп сервер , самба сервер , торрент клиент , и ещё что то было по мелочи.
Сама машинка это : Linux Debian etch3 (я своим ядром 2.6.25.6) ядро в основном тюнилось для поддержки всех сетевых протоколов и модулей + выкидывание лишнего оборудования).
Примерно 6 месяцев на нем 24/7 крутился Торрент клиент rtorrent и обменивался постоянно файлами (установлено 4 хдд примерно общим объёмом 1Тб). В летний период электрики (что б их) неоднократно вырубали электричество и сервер срывался в аварийный перегруз (в биосе стоит автоматически включаться при появлении питания) . Так вырубали не менее 3 - 5 раз . В один из такох вырубаний сервак не ожил при подключении к нему моника выяснилось что у него потеря информации на одном их разделов) . После проверки диска через fsck -f -y /dev/device
были получены файлы в папке lost&found ну и я забил на проблему (думал решилась).
Теперь столкнулся с тем что во время чтения с этого раздела информации иногда стали появляться данные (не возможно прочитать то-то и то-то). Вобщем ппц появились ББ (Bad Block).
Что имею и что делал :
сам диск это логическое продолжение системного диска т.е /dev/hda (1,2,3) где 1 это корневой раздел , 2 это свап раздел , 3 это большой раздел с ББ (Бед Блоками). На первом и третьем разделе диска стоит фс ext3 (со стандартными параметрами). Для начала прогнал :
fsck -f /dev/hda3
он стал показывать записи типа :
Error reading block 2130007 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error<y>? yes
И так примерно 20 - 30 .
на команду
fsck -f -y /dev/hda3
после проверки всё якобы нормально и проверено.
(ПС. диск отмонтирован , файлы с него все убраны , раздел удалялся и создавался заного).
Теперь запустил :
badblocks /dev/hda3 -o /bb.log -v
после чего в лог файле был список из примерно 174 записей о неисправных блоках .
после чего была запущена :
debugfs /dev/hda3
где я хотел выяснить какие innode`s равны тем нечитаемым блокам .
icheck номер_блока
(сразу скажу что когда делал первый раз у меня показал сразу номер инода по которому я выяснил какие файлы могут лежать на этом секторе :
ncheck номер_инода
после чего я скопировал (без проблем тот фаил и на повтоорную проверку мне показало что инод не занят).
Из всего списка ББ (174 записи) более ни один блок не указал на наличие какого либо инода ,т.е на команду :
icheck номер_блока
всё время выдаём что такого блока не существует .
(3 раза прогонял badblocks /dev/hda3 -o /bb_1.log -v и всё время получал один и тот же список блоков (174 записи). Но debugfs не может определить номера инодов , которые относятся к битым блокам).
Поскольку имея номер инода можно запретить навсегда возможность записи на этот сектор через команду :
cleari номер_инода
но это сделать не могу т.к нету номера инода (у меня есть подозрение что они уже выведены из обращения . но всё же почему тогда проверка на бб опять их показывает).
Вобщем главный вопрос как точно затереть битые блоки ?
Ну что никто ничего сказать не может ?
после тройной прогонки через badbloks определился стабильный список нечитаемых областей , к сожалению через debugfs по номерам этих блоков не могу найти иноды что бы их отключить (на проверку выдаёт данного блока не существует) .
я подумал что он мол сам всё замаркировал , записал туда примерно 150Гб информации (запись прошла без ошибок) но в логах в определённый момент вылезло это :
Dec 8 16:29:15 xxx kernel: res 51/40:64:5f:4e:6a/00:00:00:00:00/e2 Emask 0x9 (media error)
Dec 8 16:29:20 xxx kernel: ata3.00: configured for UDMA/133
Dec 8 16:29:20 xxx kernel: ata3: EH complete
Dec 8 16:29:20 xxx kernel: hd 2:0:0:0: [hda] 625140335 512-byte hardware sectors (320072 MB)
Dec 8 16:29:20 xxx kernel: hd 2:0:0:0: [hda] Write Protect is off
Dec 8 16:29:20 xxx kernel: hd 2:0:0:0: [hda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUAСобственно что то хотелось прочитаться но не смогло (отстой) как замаркировать битые слоки под Линуксом ?
(если убить фс и установив диск в виндовс машину с фат32 я прогоню скандиск с проверкой поверхности (мне это может помочь в убирании этих блоков если я после проверки под вендой опять установлю на тот раздел хдд ext3 ?)
Обычно при появлении сбойных секторов на винчестерах осуществляют reallocate до тех пор пока запас не будет исчерпан, после чего винт выкидывается. Краткий поиск в гугле дал http://smartmontools.sourceforge.net/BadBlockHowTo.txt
Если же все-таки хотите пометить блоки в fs, то почему бы не воспользоваться setb в debugfs?
>Обычно при появлении сбойных секторов на винчестерах осуществляют reallocate до тех пор
>пока запас не будет исчерпан, после чего винт выкидывается. Краткий поиск
>в гугле дал http://smartmontools.sourceforge.net/BadBlockHowTo.txt
>Если же все-таки хотите пометить блоки в fs, то почему бы не
>воспользоваться setb в debugfs?мм походу тема устарела но ошибибки всетаки остались
столкнулся с подобной проблемой:
на 30 машинах поставил новое железо мать проц винт - 500гб на 5 из них через месяц пошли беды , беды удалил но появились в тех же местах - как вариант заменил БП, "на время" помогло (проверка в БП ошибок не выявила) беды вернулись ковырялся дальше - програмно чики пики беды все не исчезали, сгоря заменил шнурки ata* из 5 проблема асталась на 1
итог:
-замените БП
-заменить шнурки
-знать подробности про мать (а именно на каком чипе все висит, также проконтролить градус)
другая подобная проблема :
сервер (бубен - самба =500+500+500гб)время от времени пишит .... ata3.00 ..DRDY... error
- заметил что возникает при копировании одного коталога , пока наблюдаю