LINUX.ORG.RU
Форум — Admin  

Ошибки на mdadm+ext4 при отсутсвии ошибок

 , ,


3

3 
cp: ошибка чтения «file.qcow2»: Ошибка ввода/вывода

файл лежит на ext4, которая clean (при force тоже),
которая на md0 (raid1), который (UU),
который recheck -> mismatch count=0

Внимание, вопрос: @#%&*# &^*&%^ &^%(*&% ?????????!

ps. Суська 13.1, 3.11.10 x86_64, репы стандартные + пакман и кодеки, апдейты недельной давности.

★★★

Последнее исправление: handbrake (всего исправлений: 1)
← Jamie Cameron
Доступ в интернет iptables, 4 сети →
Ответ на: комментарий от Deleted

handbrake

Ничего, как и в messages. Перед этим был инцидент, после которого массив и фс консистентны по мнению системы. Сорри, пишу с телефона.

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

Да, от рута.
debugfs сейчас возможности нет, он вроде каталог целиком берет, не ? Если да, то там весь терабайт и будет. Некуда складывать.

handbrake ★★★
() автор топика

есть продолжение песни. Похоже, при записи данных в один qcow2, эти данные попадают в другой. Все проверки молчат.

handbrake ★★★
() автор топика

ps. Суська 13.1, 3.11.10 x86_64, репы стандартные + пакман

А разве pacman - это не arch? Если арч, то источник проблемы известен %)

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

Пакман - название доп. репы в сусе, в котором собираются вещи отсутствующие в родных, типа епеля в рх. В данном случае подключен ради xbmc и vlc.
Меня другое беспокоит - mdadm и ext4 убить довольно сложно, а тут они считают себя живыми, но данные при этом портятся.

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

он вроде каталог целиком берет, не ?

Нет, конечно. Погуглите примеры, запускаете debugfs в режиме read-only и делаете там команду dump на нужный файл. Но копировать лучше на другую файловую систему (хотя бы на tmpfs), а не на эту, которая в непонятном состоянии.

Если файл скопируется, значит с raid/дисками всё в порядке и проблема уровнем выше — драйвер файловой системы, может безумные атрибуты SeLinux.

mky ★★★★★
()

Пользовался крутыми облачно-интырпрайзными приблуджами для управления виртуалками и создания снапшотов?

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

файл ~300гиг. Apparmor, se не используются, сейчас тестируются 2T, куда копия пойдет.
Запись на эту файловую была в другую виртуалку, qcow2 гиг на 80.
Не ожидал что все так плохо.

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

максимум virsh/virtmanager тойже версии с соседней машины с тойже ос и чуть более свежими апдейтами.
Снепшотам не доверяю, только q-i clone/convert, только cp/7z на другой массив, только хардкор. Отсюда и офигеваю.

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

Ну попробуйте тогда для начала просто через debufgs скопировать файл в /dev/null. Может уже даст ошибки чтения.

mky ★★★★★
()
Ответ на: комментарий от mky 
debugfs:  dump file.qcow2 /dev/null
dump: Attempt to read block from filesystem resulted in short read while reading ext2 file

при этом в dmesg 

2014-03-07T17:04:34.500429+04:00 srv kernel: [ 2591.622955] Buffer I/O error on device md0, logical block 68672976
2014-03-07T17:04:34.501372+04:00 srv kernel: [ 2591.623906] Buffer I/O error on device md0, logical block 68672992
2014-03-07T17:04:34.501381+04:00 srv kernel: [ 2591.623925] Buffer I/O error on device md0, logical block 68673008
2014-03-07T17:04:34.502405+04:00 srv kernel: [ 2591.624390] Buffer I/O error on device md0, logical block 68672976
при этом 
md0 : active raid1 sde1[3] sda1[2]
      976761392 blocks super 1.2 [2/2] [UU]
при этом
fsck.ext4 -fnv ошибок не находит
recheck массива проходит успешно, дает 0 в mismatch_count
memtest сделал 1.5 прохода, ошибок нет

хрень какая-то или я чего-то не догоняю ?

handbrake ★★★
() автор топика
Ответ на: комментарий от tazhate 
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   116   099   006    Pre-fail  Always       -       112338829
  3 Spin_Up_Time            0x0003   100   100   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       650
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   072   060   030    Pre-fail  Always       -       19860329
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       6338
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       650
183 Runtime_Bad_Block       0x0032   061   061   000    Old_age   Always       -       39
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   086   000    Old_age   Always       -       42950393910
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   064   051   045    Old_age   Always       -       36 (Min/Max 34/41)
194 Temperature_Celsius     0x0022   036   049   000    Old_age   Always       -       36 (0 20 0 0 0)
195 Hardware_ECC_Recovered  0x001a   042   022   000    Old_age   Always       -       112338829
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   199   000    Old_age   Always       -       60
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       131361574756253
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       1507029002
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       1078008273

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   111   099   006    Pre-fail  Always       -       39096672
  3 Spin_Up_Time            0x0003   100   100   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       649
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   072   060   030    Pre-fail  Always       -       20467257
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       6337
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       649
183 Runtime_Bad_Block       0x0032   093   093   000    Old_age   Always       -       7
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       7
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   063   050   045    Old_age   Always       -       37 (Min/Max 33/41)
194 Temperature_Celsius     0x0022   037   050   000    Old_age   Always       -       37 (0 21 0 0 0)
195 Hardware_ECC_Recovered  0x001a   034   021   000    Old_age   Always       -       39096672
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       31
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       86011015077738
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       1651215351
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       1915186557

старые, но речек то проходит, после выноса инфы в тестирование пойдут

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

хотя как старые, меньше года в работе
Model Family: Seagate Barracuda 7200.12
Device Model: ST31000524AS
и ругань не на sd, а на md

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

Cпасибо, на прибытые гвоздями показатели смартов смотреть не интересно. Да и больше года у меня нигде WD не жили. Сигейты хотябы дохнут вполне предсказуемо и не целиком, а wd, те что видел, сразу в кирпич.
Я вижу что не фонтан, диски дергались и на ходу с отмонтированием. Бэды эти уже давно.
Что конкретно не нравится ?
И как физика объясняет, то что записанное на рейде в 1 файл обнаруживается в другом ?

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

Да и больше года у меня нигде WD не жили

Есть хорошие модели - wd red/wd raptor, есть говно - wd black/ wd blue/wd green. Знать надо, чо выбираешь.

Сигейты хотябы дохнут вполне предсказуемо и не целиком

синдром утенка

Что конкретно не нравится ?

А что тебе самому не нравится? Никакие параметры ниначто не намекают, не?

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

Если это все сообщения, что выводятся в dmesg, то странно, там при таких ошибках должна быть куча ошибок, связанных с диском (sda, sde), а не только про md0.

Про badblocks написали, ещё можно запустить smart тест винта (long), и ещё посмотреть SMART log винта, если при «Buffer I/O error on device md0» в log'е винта не появляется ошибка чтения (READ DMA error), то это очень странно. А если ошибка появляется в log'е винта, но не появляется в dmesg, то тоже странно.

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

не верю бб, обманывал пару раз :\ под mhdd сейчас.
мне много что-там не нравится, но сиги с похожими показателями еще год спокойно работают.
У нас разная статистика, по моей, они еще вполне. По твоей нет, что не нравится ?

handbrake ★★★
() автор топика

Я видел абсолютно такие же симптомы, а также рандомные сегфолты когда была битая плашка оперативы. Причём MHDD говорил что всё ок, пока я не психанул и не начал проверять плашки по одной.

Хз, что это было, разбираться было лень - заменил плашку, проблема исчезла.

В смарте первым делом смотреть надо на Offline_Uncorrectable и Reallocated sectors count - если они отличны от нуля, винту может прийти жопа в любой момент(может проработать пару лет и всё будет ок, может навернуться хоть завтра). Ну и на UDMA_CRC_Error_Count, но последнее скорее говорит либо о накрывающемся контроллере жестких дисков(редко, очень редко), либо чаще - о хреновом кабеле. В любом случае, там - не газиллион ошибок, и вряд ли это причина.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от mky

Поэтому и тему поднял. Диски ковырять и восстанавливать доводилось, практически уверен, что эти st пройдут, поэтому про смарты и не писал. Инцидент о котором я упомянул вначале - после добавления диска для снятия инфы (кстати, это WD RE4, чтоб его) произошел массовый отвал дисков, в процессе копирования (половины массивов на разных контролерах висели, разлетелись со всех, все они при этом clean, система собрать массивы не смогла, но вручную собрались обычным assemble scan и add, re-add не прошел). Единственное что могло быть неправильным это сбор массивов по старшим эвентам. После всего этого был fsck. Сейчас все UU, clean, и т.п., при том что явно есть повреждения и они не фиксируются в системах считающихся надежными.
Развал и пересбор в продакшне обычное дело, вопрос - как быть уверенным, если если после вполне стандартного fail/recovery получаешь проблему, которая выплывает только на 3й день и ни одна диагностика ни на что не ругается.

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

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

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

Если ты сделал стойку на Raw_Read_Error_Rate и Seek_Error_Rate , то расслабься.

У seagate в эти переменные записывается общее количество обращений. А в 4 старших битах - собственно ошибки. Поэтому числа страшные, но реально ошибок нет

Правильно смотреть так:

smartctl -a /dev/sdd -v 7,hex48 -v 1,hex48 | less

http://forums.seagate.com/t5/Desktop-HDD-Desktop-SSHD/Seagate-s-Seek-Error-Ra...

Не говоря уже о том, что поле WHEN_FAILED чистое. Поздравляю, шеврон диванного теоретика ты честно заработал %)

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

Ещё, если есть возможнось, я бы запустил принудительную проверку массива.

Обычно штатный скрипт для cron есть в пакете с mdadm. Основное действие

echo «check» > /sys/block/mdX/md/sync_action

Вдруг действительно попался один сбойный сектор на винте, и mdadm прочитал с двух зеркальных половин разные данные.

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

Спасибо за доброе слово, но все самое интересное вы пропустили:
1. cheсk еще в посте был, а также recheck, memtest, fsck и debugfs и другие пляски о которых я не писал.
2. Пост посвящен тому, что _ни_одна_проверка_ _ничего_не_кажет_, при том, что часть данных при этом не читается, а при записи на массив новые данные портят имеющиеся.
3. а еще есть i/o error на md при полном отсутствии таковых с sd*

а)Не исключено, что я на баг какой-то наткнулся в mdadm/ext4.
б)проверьте ваши железки, допустим они тоже ошибок не покажут. А теперь это оказывается ни разу не показатель и прямо сейчас идет порча данных, при которой бэкапы эту порчу наследуют.

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

После всего этого был fsck.

Хватит уже говорить про fsck, он не тестирует диск, поэтому пока повреждения не затронут сектора с метаданными ФС, fsck никак не отреагирует на ошибки диска.

практически уверен, что эти st пройдут,

Хорошо, зайдём с другой стороны, как давно датированы ошибки в SMART-логе, там где хранится 5 последних ошибок диска?

и они не фиксируются в системах считающихся надежными.

Странно, почему RedHat в своих системах использует ядро 2.6.32? Может поведение вашей системы вобще связано с этой ошибкой http://lkml.org/lkml/2014/2/20/736 .

и ни одна диагностика ни на что не ругается

badblocks на /dev/md0, /dev/sda, /dev/sde проходит успешно?

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

Что насчёт Runtime_Bad_Block и Command_Timeout?

Не сталкивался. Судя по отношению WORST к THRESH, в Runtime_Bad_Block что-то похожее на реальное число бед-блоков.

Command_Timeout у первого винта просто огромный, но опять же атрибут не отмечен в WHEN_FAILED, да и WORST неплох. Скорее всего тоже нужно смотреть на определённые биты.

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

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

Есть мнение что это именно тебе попался бажный контроллер/драйвер на контроллер жестких дисков. Если уж memtest ничего не кажет.

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

С этим вынужден согласится, контроллер у меня так-себе, это встроенный в h77 в режиме ahci. Интересно, в других чипсетах контроллеры отличаются ?
Этот все работало ~полгода, переваривая террабайты по которым сходилась md5.
Закончился mhdd, разберусь как тут фотки постят, обрежу и выложу, вкратце, как я и говорил с ними все в порядке.
Сейчас идет badblocks -svvv /dev/md0...

handbrake ★★★
() автор топика

badblocks -vsss /dev/md0 

Checking blocks 0 to 976761391
Checking for bad blocks (read-only test): 274691904one, 37:14 elapsed. (0/0/0 errors)
274691905one, 37:14 elapsed. (1/0/0 errors)
274691906one, 37:14 elapsed. (2/0/0 errors)
274691907one, 37:14 elapsed. (3/0/0 errors)
274691968one, 37:14 elapsed. (4/0/0 errors)
274691969one, 37:14 elapsed. (5/0/0 errors)
274691970one, 37:14 elapsed. (6/0/0 errors)
274691971one, 37:14 elapsed. (7/0/0 errors)
274692032one, 37:14 elapsed. (8/0/0 errors)
274692033one, 37:14 elapsed. (9/0/0 errors)
274692034one, 37:14 elapsed. (10/0/0 errors)
274692035one, 37:14 elapsed. (11/0/0 errors)
274692096one, 37:14 elapsed. (12/0/0 errors)
274692097one, 37:14 elapsed. (13/0/0 errors)
274692098one, 37:14 elapsed. (14/0/0 errors)
274692099one, 37:14 elapsed. (15/0/0 errors)
274692160one, 37:14 elapsed. (16/0/0 errors)
274692161one, 37:14 elapsed. (17/0/0 errors)
274692162one, 37:14 elapsed. (18/0/0 errors)
274692163one, 37:14 elapsed. (19/0/0 errors)
274692224one, 37:14 elapsed. (20/0/0 errors)
274692225one, 37:14 elapsed. (21/0/0 errors)
274692226one, 37:14 elapsed. (22/0/0 errors)
274692227one, 37:14 elapsed. (23/0/0 errors)
274692288one, 37:14 elapsed. (24/0/0 errors)
274692289one, 37:14 elapsed. (25/0/0 errors)
274692290one, 37:14 elapsed. (26/0/0 errors)
274692291one, 37:14 elapsed. (27/0/0 errors)
274692352one, 37:14 elapsed. (28/0/0 errors)
274692353one, 37:14 elapsed. (29/0/0 errors)
274692354one, 37:14 elapsed. (30/0/0 errors)
...пропущено...
274693441one, 37:14 elapsed. (97/0/0 errors)
274693442one, 37:14 elapsed. (98/0/0 errors)
274693443one, 37:14 elapsed. (99/0/0 errors)
274693504one, 37:14 elapsed. (100/0/0 errors)
274693505one, 37:14 elapsed. (101/0/0 errors)
274693506one, 37:14 elapsed. (102/0/0 errors)
274693507one, 37:14 elapsed. (103/0/0 errors)
274693568one, 37:14 elapsed. (104/0/0 errors)
274693569one, 37:14 elapsed. (105/0/0 errors)
274693570one, 37:14 elapsed. (106/0/0 errors)
274693571one, 37:14 elapsed. (107/0/0 errors)
274693632one, 37:14 elapsed. (108/0/0 errors)
274693633one, 37:14 elapsed. (109/0/0 errors)
274693634one, 37:14 elapsed. (110/0/0 errors)
274693635one, 37:14 elapsed. (111/0/0 errors)
274693696one, 37:14 elapsed. (112/0/0 errors)
274693697one, 37:14 elapsed. (113/0/0 errors)
274693698one, 37:14 elapsed. (114/0/0 errors)
274693699one, 37:14 elapsed. (115/0/0 errors)
274693760one, 37:14 elapsed. (116/0/0 errors)
274693761one, 37:14 elapsed. (117/0/0 errors)
274693762one, 37:14 elapsed. (118/0/0 errors)
274693763one, 37:14 elapsed. (119/0/0 errors)
274693824one, 37:14 elapsed. (120/0/0 errors)
274693825one, 37:14 elapsed. (121/0/0 errors)
274693826one, 37:14 elapsed. (122/0/0 errors)
274693827one, 37:14 elapsed. (123/0/0 errors)
274693888one, 37:14 elapsed. (124/0/0 errors)
274693889one, 37:14 elapsed. (125/0/0 errors)
274693890one, 37:14 elapsed. (126/0/0 errors)
274693891one, 37:14 elapsed. (127/0/0 errors)
46.82% done, 1:07:09 elapsed. (128/0/0 errors)
/var/log/messages 
2014-03-08T17:04:36.211563+04:00 srv kernel: [ 2391.094387] Buffer I/O error on device md0, logical block 68672976
2014-03-08T17:04:36.211582+04:00 srv kernel: [ 2391.094394] Buffer I/O error on device md0, logical block 68672976
2014-03-08T17:04:36.211585+04:00 srv kernel: [ 2391.094453] Buffer I/O error on device md0, logical block 68672976
2014-03-08T17:04:36.211590+04:00 srv kernel: [ 2391.094490] Buffer I/O error on device md0, logical block 68672976
2014-03-08T17:04:36.212530+04:00 srv kernel: [ 2391.094525] Buffer I/O error on device md0, logical block 68672976
2014-03-08T17:04:36.214535+04:00 srv kernel: [ 2391.096592] Buffer I/O error on device md0, logical block 68672992
2014-03-08T17:04:36.214547+04:00 srv kernel: [ 2391.096620] Buffer I/O error on device md0, logical block 68672992
2014-03-08T17:04:36.214551+04:00 srv kernel: [ 2391.096642] Buffer I/O error on device md0, logical block 68672992
2014-03-08T17:04:36.214553+04:00 srv kernel: [ 2391.096663] Buffer I/O error on device md0, logical block 68672992
2014-03-08T17:04:36.215546+04:00 srv kernel: [ 2391.098342] Buffer I/O error on device md0, logical block 68673008

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

ну если ошибок при разных режимах работы mhdd не выявлено и memtest тоже проблем не кажет, значит скорее всего проблема в драйвере ядра. Пиши багрепорт.

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

Хочу уточнить, а mhdd запускался на этом же сервере/контроллере, или диски подключались к другому?

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

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

Работали до сбоя на разных контроллерах: один на интегрированном этой матери, второй на stlabs-400 (как HBA) в ней же. Грешу на него, но по отдельности с ним все в порядке. После сбоя все было повешено на встроенный интел.
При сбое, мдадм на половины рейдов повесил по 512 бб и они были с большими эвентами, по ним рейд и собирался. Кстати не они ли в логе и вылазят, хотя логике, какой смысл давать доступ к сбойным блокам рейда, да и по цифрам, если я правильно их понимаю, не сходится...

handbrake ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Jamie Cameron
Admin
Доступ в интернет iptables, 4 сети →