Redimensionou a partição para um valor muito pequeno após o encolhimento do sistema de arquivos

Question

Eu reduzi um sistema de arquivos ext4 com resize2fs :

resize2fs -p /dev/sdn1 3500G

(FS é usado para 2,3 TB)

Em seguida, redimensionei a partição com parted e deixei uma margem de 0,3% (~ 10 GB) ao definir o novo fim:

(parted) resizepart 1 3681027097kb

Por fim, isso ficou muito restrito:

# e2fsck -f /dev/sdn1
e2fsck 1.42.9 (4-Feb-2014)
The filesystem size (according to the superblock) is 917504000 blocks
The physical size of the device is 898688000 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

Em seguida, redimensionei a partição novamente, desta vez com margem de 3%:

(parted) resizepart 1 3681027097kb

Depois disso, as verificações do sistema de arquivos passam:

# e2fsck -f /dev/sdn1
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdn1: 278040/114688000 files (12.4% non-contiguous), 608536948/917504000 blocks

Eu executei partprobe /dev/sdn depois dos dois comandos resizepart .

Eu não montei o sistema de arquivos em todo o processo (e nem o montei ainda).

O passo intermediário em que eu redimensionei a partição para um valor muito pequeno corrompeu o fs?

A execução bem-sucedida de e2fsck é suficiente para garantir que os dados não foram danificados?

    

Answer 1

I resized the partition to a too small value have corrupted the fs?

É improvável no seu caso, especialmente desde que você teve a gentileza de parar com o fs (c) killer, mas você não pode descartar a possibilidade completamente.

Por exemplo, a corrupção acontece quando é uma partição lógica dentro da partição estendida de uma tabela de partições msdos. As partições lógicas são listas vinculadas, portanto, entre partições lógicas, há um setor usado para apontar para a próxima partição na lista. Se você encolher / redimensionar essa partição lógica, haverá um setor (parcialmente) sobrescrito em algum lugar no meio do disco.

Além disso, alguns programas particionadores podem aproveitar o zeramento. Este também é o caso do LVM, em cada lvcreate ele zera como o primeiro 4K do LV criado, e além disso não há garantia de que reverter um lvresize fracassado dará as mesmas extensões que foram usadas antes. Se não tiver sorte, o LV pode estar localizado fisicamente em outro lugar, e é por isso que você só pode desfazer tais acidentes por vgcfgrestore algo de /etc/lvm/{backup,archive}/ que foi criado antes do lvrize.

Com SSDs, há essa modalidade TRIM que faz com que todo tipo de programa emita comandos TRIM para o SSD. O LVM faz isso se issue_discards=1 em lvm.conf (sempre o define como 0), e espera-se que os vários programas de particionamento nunca adotem esse comportamento.

Is the successful run of e2fsck enough to be sure that data has not been damaged?

A maioria dos sistemas de arquivos não consegue detectar a corrupção de dados fora de seus próprios metadados. O que geralmente não é um problema, já que você não deveria fazer acrobacias como essas. Se você tem um backup, você pode comparar registros de tempo / checksums com o que você tem em seus backups.

I haven't mounted the filesystem in the whole process (and not mounted it yet even).

Você pode montá-lo como somente leitura assim:

mount -o loop,ro /dev/sdn1 /mnt/somewhere

e, em seguida, confira os arquivos.

O loop,ro informa ao mount para criar um dispositivo de loop somente leitura e montá-lo. Surpreendentemente, ro por si só não garante a prontidão para alguns sistemas de arquivos, incluindo ext4 . (E para sistemas de arquivos com vários dispositivos, como btrfs , o loop,ro também não afeta, porque afeta apenas um dispositivo, não todos).