e2fsck / resize2fs problemas

Question

Eu tenho 6 unidades (cada uma com 1.5T, todas do mesmo modelo e revisão de firmware) que fazem parte de um array RAID5. O RAID5 faz um grupo de volumes LVM e um grupo lógico. Este último contém apenas uma partição ext3. Eu recentemente corri:

e2fsck -f /dev/vg03/lv01 && resize2fs -M /dev/vg03/lv01

que saiu sem erro.

Agora, quando tento mount /dev/vg03/lv01 , obtenho:

EXT3-fs error (device dm-0): ext3_check_descriptors: Block bitmap for group 30533 not in group (block 1000532368)!
  EXT3-fs: group descriptors corrupted!

Como eu saio dessa situação? Esta é toda a informação que posso fornecer atualmente:

fdisk -l /dev/sd[cdefgh] mostra (corretamente) que eles são " Linux raid autodetect "

mas o fdisk agora mostra:

fdisk -l /dev/md0

Disk /dev/md0: 7501.5 GB, 7501495664640 bytes

...
Disk identifier: 0x00000000
Disk /dev/md0 doesn't contain a valid partition table

(em vez de uma partição do tipo LVM)

fdisk -l /dev/vg03/lv01

Disk /dev/vg03/lv01: 7501.5 GB, 7501491732480 bytes
...
Disk identifier: 0x00000000
Disk /dev/vg03/lv01 doesn't contain a valid partition table

(em vez de uma partição do tipo ext3)

Eu tentei:

e2fsck -fy /dev/vg03/lv01

e2fsck 1.41.12 (17-May-2010)
e2fsck: Group descriptors look bad... trying backup blocks...
Block bitmap for group 30533 is not in group. (block 1000532368)
Relocate? yes

Inode bitmap for group 30533 is not in group. (block 1000532369)
Relocate? yes

Pass 1: Checking inodes, blocks, and sizes
Relocating group 30533's block bitmap to 1000524246...
Error allocating 1 contiguous block(s) in block group 30533 for inode bitmap: Could not allocate block in ext2 filesystem
e2fsck: aborted

Informações adicionais que posso fornecer:

cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active (auto-read-only) raid5 sdg1[0] sdh1[5] sdf1[4] sde1[3] sdc1[2] sdd1[1]
7325679360 blocks level 5, 128k chunk, algorithm 2 [6/6] [UUUUUU]
bitmap: 1/175 pages [4KB], 4096KB chunk

unused devices:

Por último, todos os testes de smartctl (curto e prolongado) não mostraram erros em nenhum dos discos.

Devo tentar resize2fs aumentar /dev/vg03/lv01 e refazer e2fsck ? Devo eu cfdisk /dev/md0 e /dev/vg03/lv01 voltar para seus tipos reais?

Agradecemos antecipadamente por toda e qualquer ajuda.

2011-09-20 ATUALIZAÇÃO

Eu emiti os seguintes comandos e consegui remontar a partição, mas visualizando o tamanho ( df ) de antes e depois, parece que 1Tb de dados desapareceram. Ao verificar o MD5SUMS (de um backup antigo) de alguns arquivos com os "mesmos" arquivos da partição remontada, alguns erros foram detectados.

Os comandos emitidos para remontar a partição foram:

dumpe2fs /dev/vg03/lv01

  Block count: 1000491435<br />
  Block size:  4096<br />

tune2fs -O ^has_journal /dev/vg03/lv01

resize2fs -p /dev/vg03/lv01

dumpe2fs /dev/vg03/lv01

  Block count: 1831418880<br />
  Block size:  4096<br />

mount -o ro,noatime /dev/vg03/lv01 /mnt/raid

  OK... but files have been damaged / gone missing.

    

Answer 1

Como você criou o LVM em primeiro lugar? Você preparou o volume físico usando /dev/md0 ou fez um fdisk primeiro e usou uma das partições como volume físico.

Se você usou o dispositivo inteiro como um PV, então fdisk não irá funcionar nele, pois as informações do LVM serão colocadas, onde fdisk espera encontrar uma tabela de partições.

O que você pode querer verificar é fazer um vgdisplay -v /dev/vg03 para ver quais volumes físicos estão presentes no grupo de volumes.

    

Answer 2

Você tem o RAID 5 de 6 sd * dispositivos de bloco sem partições. Agora, você tem o lvm no raid md0. Assim, você cria o volume físico de md0, o grupo de volumes denominado vg03 e um volume lógico denominado lv01. lv01 consiste em sistema de arquivos ext3, que você quer aumentar / diminuir.

Ao realizar essa ação: e2fsck -f / dev / vg03 / lv01 & & resize2fs -M / dev / vg03 / lv01 você está tentando diminuir o sistema de arquivos, que era exacly ext3 (com journal).

Tanto quanto eu sei, resize2fs pode redimensionar os sistemas de arquivos ext2, mas não os sistemas de arquivos ext3, então você deve remover o journal primeiro.

Agora, quando você faz isso por tunefs, você pode voltar ao sistema de arquivos de trabalho, que foi quebrado por resize2fs e fsck depois.

Nesse ponto, posso aconselhá-lo a usar apenas alguns softwares de recuperação específicos, como ext3 undelete ou qualquer outra coisa ...