LINUX.ORG.RU

Не монтируется XFS на RAID/Сломанная ФС или сломанный RAID

 , ,


0

1

Прошу помочь.

Есть у меня на домашнем сервере софтовый рэйд 5 (mdadm) из 4-х винтов по 3ТБ каждый и XFS на весь рэйд. В основном файлопомойка. Служил без проблем. На днях один из винтов умер. Мне на это пришло уведомление, но сами данные были доступны и в общем все работало. Оно и понятно, что так и должно было быть, ведь это raid5. На выходных, т.е. сегодня, я решил что надо посмотреть какой именно винт сдох и не нашел ничего умнее, чем отключив демона mdadm вырубить сервер и попробовать физически отключать по одному винты, запускать потом и смотреть какие sdX «исчезли» (монитор к нему не подключен, все делал через ssh). Думаю логика понятна. Но в процессе, как я понял, выпендрился BIOS - порядок дисков поменялся и когда я вернул как было, то raid показывался как неактивный с 3 винтами с меткой (S) у каждого.

В общем после гугления я сделал так:

mdadm --stop /dev/md0
mdadm --assemble --scan -v

После такого raid вроде ожил. Но после перезагрузки системы снова был неактивным. Я пробовал заменять в /etc/mdadm.conf на выхлоп mdadm --examine --scan, но с ним почему-то не определялось в /dev/md0. В общем в итоге со старым /etc/mdadm.conf оно завелось и решил, что проблема решена, надо только замонтировать разделы. Тут я вспомнил, что все экперименты по восстановлению рейда делал не закоментировав монтирование в /etc/fstab, но по идее это не должно было приводить к проблемам, ведь все это время монтирование не должно было проходить. Возможно я ошибался. Когда я попробовал замонтировать вручную, то получил такое:

# mount /dev/md0 /files
mount: mount /dev/md0 on /files failed: Structure needs cleaning

Гугление оптимизма не добавило. Вот что выдал xfs_repair /dev/md0:

Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

Я боюсь использовать -L. Я пытался нагуглить что именно в данном случае означает очистка журнала. Если пропадут последние изменения допустим за несколько часов, то пофиг. Терять данные очень не хочется.

Кстати монтирование read only с norecovery тоже не вышло - пишет туже ошибку.

Винт на замену еще не купил, но судя по симптомам это может не помочь.

Приведу /proc/mdstat на момент сбоя, но когда все работало

Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [raid10] [linear] [multipath] 
md0 : active raid5 sdc1[0](F) sdb1[4] sde1[3] sda1[1]
      8790792192 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [_UUU]
      
unused devices: <none>
и на текущий
Personalities : [raid6] [raid5] [raid4] [raid0] [raid1] [raid10] [linear] [multipath] 
md0 : active raid5 sdb1[0] sdd1[3] sda1[1]
      8790792192 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
      
unused devices: <none>

Еще от mdadm на текущий момент:

# mdadm --examine --scan
ARRAY /dev/md0 UUID=45944250:b5a10965:72b3103c:136c2f80
ARRAY /dev/md/data  metadata=1.2 UUID=0b86cf4c:34ccaddd:0a50085a:384810a3 name=dark-river:data
# mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 name=dark-river:data UUID=0b86cf4c:34ccaddd:0a50085a:384810a3
И из /etc/mdadm.conf:
ARRAY /dev/md0 metadata=1.2 name=dark-river:data UUID=0b86cf4c:34ccaddd:0a50085a:384810a3

Меня здесь смущает, что у mdadm --examine --scan два ARRAY с разными UUID и если эти две строки скопировать в /etc/mdadm.conf заместо той, что выше, то /dev/md0 нет, а только md127 (точно номер не помню) как автоматически определенный и в режиме только на чтение.

А так mdadm рапортует, что у него все отлично, ну кроме того, что одного устройства не хватает (DegradedArray). Могу показать другие выхлопы, просто и так очень много текста вышло. Честно говоря не понимаю почему такое произошло.


Смотреть состояние нужно хотя бы так.

# mdadm -D /dev/md127
/dev/md127:
        Version : 1.2
  Creation Time : Wed Jan 12 14:40:56 2011
     Raid Level : raid5
     Array Size : 2815994880 (2685.54 GiB 2883.58 GB)
  Used Dev Size : 563198976 (537.11 GiB 576.72 GB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Sat Aug  8 21:04:23 2015
          State : clean 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 1024K

           Name : myraidname:0
           UUID : e081b200:dc286ba8:ac24aac9:e15b01f8
         Events : 686911

    Number   Major   Minor   RaidDevice State
       4       8       33        0      active sync   /dev/sdc1
       5       8       65        1      active sync   /dev/sde1
       8       8        1        2      active sync   /dev/sda1
       6       8       17        3      active sync   /dev/sdb1
       7       8       49        4      active sync   /dev/sdd1
       9       8       81        5      active sync   /dev/sdf1

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

Я так тоже смотрел, не привел выхлоп, как уже писал, просто потому что и так много вышло. Вот:

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed May  1 18:36:03 2013
     Raid Level : raid5
     Array Size : 8790792192 (8383.55 GiB 9001.77 GB)
  Used Dev Size : 2930264064 (2794.52 GiB 3000.59 GB)
   Raid Devices : 4
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Sat Aug  8 18:13:37 2015
          State : clean, degraded 
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : dark-river:data  (local to host dark-river)
           UUID : 0b86cf4c:34ccaddd:0a50085a:384810a3
         Events : 20319

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8        1        1      active sync   /dev/sda1
       3       8       49        2      active sync   /dev/sdd1
       6       0        0        6      removed

Vark ()

xfs_repair -L уберет журнал и данные накопившиеся со времени последнего нормального отмонтирования. Если ты выключил сервак с ноги, то да возможны проблемы, если нет, то оно уберет тебе, то что накопилось там в процессе твоих экспериментов с рейдом (не делай так больше). Удачи.

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

Спасибо. Починил. Правда xfs_repair -L у меня на 3-й стадии упал по сегфолту, потом ему памяти не хватало, в но в итоге вроде починил файлуху. Сделал мне lost+found на 27 гигов, но это я потом посмотрю, что там есть и надо ли что-то с этим делать. Судя по некоторым признакам какие-то проблемы со структурой XFS давно были и потому видимо и наложилось с проблемами с рейдом. Сколько я не думал, я не смог найти других объяснений проблемы. Мои «эксперименты» с рейдом экспериментами то сложно назвать, т.е. никакие мои действия (из тех что были, а не любые возможные конечно), если верить манам, не должны были привести к подобному.

Кстати загадка двух ARRAY была разгадана и к проблеме не имеет отношения. Оказалось пятый, системный диск, когда-то был в рейде, а мета о нем «выжила», вот и светилась.

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