tune2fs ainda mostra “Número mágico ruim no super-bloco” mesmo depois que os erros do sistema de arquivos são corrigidos usando fsck

Question

Consigo recuperar um sistema de arquivos corrompido associado a um dispositivo drbd.

Mas depois de recuperar usando 'fsck', tune2fs (tunes2fs -l lv_name) ainda mostra 'Bad magic number em super-block ..' embora o respectivo dispositivo drbd mostre-o como limpo (tunes2fs -l drbd_device).

saída do tune2fs --- > antes de corromper o sistema de arquivos

# tune2fs -l /dev/drbd1
tune2fs 1.42.12 (29-Aug-2014)
Filesystem volume name:   drbd1
Last mounted on:          <not available>
Filesystem UUID:          da7a8a84-4fef-4e6a-a1c3-1147ba2e1c8e
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super 
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
...

# tune2fs -l /dev/VG1/test_lv
tune2fs 1.42.12 (29-Aug-2014)
Filesystem volume name:   drbd1
Last mounted on:          <not available>
Filesystem UUID:          da7a8a84-4fef-4e6a-a1c3-1147ba2e1c8e
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super 
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
...

Super bloqueio de corrupção

# dd if=/dev/zero of=/dev/VG1/test_lv count=1 bs=4096
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000107652 s, 38.0 MB/s

saída do tune2fs --- > depois da corrupção do sistema de arquivos

# tune2fs -l /dev/drbd1
tune2fs 1.42.12 (29-Aug-2014)
tune2fs: Bad magic number in super-block while trying to open /dev/drbd1
Couldn't find valid filesystem superblock.

# tune2fs -l /dev/VG1/test_lv
tune2fs 1.42.12 (29-Aug-2014)
tune2fs: Bad magic number in super-block while trying to open /dev/VG1/test_lv
Couldn't find valid filesystem superblock.

Recuperado usando fsck

# fsck -fy /dev/drbd1
fsck 1.42.12 (29-Aug-2014)
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
Superblock last write time is in the future.
    (by less than a day, probably due to the hardware clock being incorrectly set).  Fix? yes
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
drbd1: ***** FILE SYSTEM WAS MODIFIED *****
drbd1: 11/128016 files (0.0% non-contiguous), 26699/511948 blocks

Dispositivo DRBD exibido como limpo

saída do tune2fs --- > depois de recuperar os erros do sistema de arquivos

# tune2fs -l /dev/drbd1
tune2fs 1.42.12 (29-Aug-2014)
Filesystem volume name:   drbd1
Last mounted on:          <not available>
Filesystem UUID:          da7a8a84-4fef-4e6a-a1c3-1147ba2e1c8e
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
...

# tune2fs -l /dev/VG1/test_lv
tune2fs 1.42.12 (29-Aug-2014)
tune2fs: Bad magic number in super-block while trying to open /dev/VG1/test_lv
Couldn't find valid filesystem superblock.

While corrupting the super block, lv name is provided in the command whereas in recovery, drbd device name.

When File system is associated with drbd, Is it ok to execute tune2fs on LV?

My understanding is that we should not rely on LV, when filesystem is associated with drbd. Please correct me if I am wrong.

Por favor, ajude a entender a diferença de comportamento do comando tune2fs com o nome DRBD e lv.