Partition LVM en erreur une fois formatée

Bonjour,

j’ai une partition LVM créé avec lvcreate -n base-home -L 2G vg01
Où vg01 est le volume group (qui dispose de largement assez de place.

Je formate cette partition avec mkfs -t ext 4 /dev/mapper/vg01-base--home
Pas d’erreur.

Ensuite je monte la partition avec mount -t ext4 /dev/mapper/vg01-base--home /mnt/vm-part
Où /mnt/vm-part a été créé par mkdir /mnt/vm-part

mais si je fais ls -al /mnt/vm-part j’obtiens l’erreur suivante:

# ls -al /mnt/vm-part
ls: lecture du répertoire '/mnt/vm-part': Message invalide
total 0

Et avec e2fsck:

# e2fsck -f -n /dev/mapper/vg01-base--tmp
e2fsck 1.46.2 (28-Feb-2021)
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
Inode 7, i_blocks is 12248, should be 8.  Fix? no

Pass 2: Checking directory structure
Directory inode 2, block #0, offset 0: directory corrupted
Salvage? no

e2fsck: aborted

/dev/mapper/vg01-base--tmp: ********** WARNING: Filesystem still has errors **********

Alors que la même commande après le formatage ne donnait aucune erreur:

# e2fsck -f -n /dev/mapper/vg01-base--tmp
e2fsck 1.46.2 (28-Feb-2021)
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/mapper/vg01-base--tmp: 11/131072 files (0.0% non-contiguous), 26156/524288 blocks

si je corrige les erreur de directory corrupted, tout revient à la normale.

# e2fsck -f /dev/mapper/vg01-base--tmp
e2fsck 1.46.2 (28-Feb-2021)
Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 2, block #0, offset 0: directory corrupted
Salvage<y>? yes
Missing '.' in directory inode 2.
Fix<y>? yes
Setting filetype for entry '.' in ??? (2) to 2.
Missing '..' in directory inode 2.
Fix<y>? yes
Setting filetype for entry '..' in ??? (2) to 2.
Directory inode 11, block #0, offset 0: directory corrupted
Salvage<y>? yes
Missing '.' in directory inode 11.
Fix<y>? yes
Setting filetype for entry '.' in ??? (11) to 2.
Missing '..' in directory inode 11.
Fix<y>? yes
Setting filetype for entry '..' in ??? (11) to 2.
Directory inode 11, block #1, offset 0: directory corrupted
Salvage<y>? yes
Directory inode 11, block #2, offset 0: directory corrupted
Salvage<y>? yes
Directory inode 11, block #3, offset 0: directory corrupted
Salvage<y>? yes
Pass 3: Checking directory connectivity
'..' in / (2) is <The NULL inode> (0), should be / (2).
Fix<y>? yes
Unconnected directory inode 11 (/???)
Connect to /lost+found<y>? yes
/lost+found not found.  Create<y>? yes
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Inode 11 ref count is 3, should be 2.  Fix<y>? yes
Pass 5: Checking group summary information
Block bitmap differences:  +8487
Fix<y>? yes
Free blocks count wrong for group #0 (24282, counted=24283).
Fix<y>? yes
Free blocks count wrong (498133, counted=498134).
Fix<y>? yes

/dev/mapper/vg01-base--tmp: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mapper/vg01-base--tmp: 12/131072 files (0.0% non-contiguous), 26154/524288 blocks

# mount -t ext4 /dev/mapper/vg01-base--tmp /mnt/vm-part
# ls -al /mnt/vm-part/
total 12
drwxr-xr-x 3 root root 4096  4 août  13:28 .
drwxr-xr-x 5 root root 4096  2 août  13:37 ..
drwx------ 3 root root 4096  4 août  13:45 lost+found

Toutes les commandes sont faite en tant que root (pas de sudo)
je ne comprends pas où est le problème…

Avec une espace entre « ext » et « 4 », vraiment ?

Jamais vu ce message d’erreur…
Il y a des messages dans les logs du noyau ?

Ce n’est pas le même volume. base-home != base-tmp.

Notes :
C’est un volume logique, pas une partition.
Eviter le « - » dans les noms de groupe ou de volume, ça se transforme en « -- » et c’est très laid. Utiliser plutôt" « _ ».
Les noms de groupe ausi peu évocateurs que « vg01 » devraient être bannis.

faute de frappe en écrivant le message, ce qui est évidant car sinon la commande aurait renvoyé une erreur.

oui je n’avais pas regardé:

Aug  4 13:51:34 dsrvxen01 kernel: [161086.232563] EXT4-fs warning (device dm-14): ext4_dirblock_csum_verify:377: inode #2: comm ls: No space for directory leaf checksum. Please run e2fsck -D.
Aug  4 13:51:34 dsrvxen01 kernel: [161086.232567] EXT4-fs error (device dm-14): htree_dirblock_to_tree:1003: inode #2: comm ls: Directory block failed checksum

Le e2fsck -D répare le filesystem. A la différence du cas précédent évoqué (avec l’argument -f) les autres partitions fonctionnent.
je ne comprends pas comment au départ cela a pu se produite et à quel niveau le problème se pose.
En recréant un LV, puis format, puis mount, j’ai de nouveau la même erreur.
En clair j’ai systématiquement l’erreur quelque soit le LV que je créé.
C’est apparement lié au volume group mais je ne sais pas pourquoi. Je l’ai déjà supprimé et refait complètement.
Sur le nvme j’ai un VG nommé vg00 de 60 GB sur lequel est installé la debian avec xen. puis j’ai créé une nouvelle partition avec le reste mis dans un VG vg01.

~# fdisk -l /dev/nvme0n1
Disque /dev/nvme0n1 : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : TS1TMTE240S
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : EA006C9A-57EE-49DF-A511-238F9AF4A16D

Périphérique       Début        Fin   Secteurs Taille Type
/dev/nvme0n1p1      2048     194559     192512    94M Système EFI
/dev/nvme0n1p2    194560  125194239  124999680  59,6G LVM Linux
/dev/nvme0n1p3 125194240 1953523711 1828329472 871,8G LVM Linux

Désolé, faute de recopie, j’ai fait deux fois le test avec deux LV. Pour les erreur kern.log j’ai fait un troisième essai avec un autre LV. considère que l’on parle du même, les erreurs sont les même quelque soit le LV que j’utilise.

Oui j’oublie toujours cette histoire de tiret. en fait comme ce sont des LV de partitions de VMs xen, je suis obligé de mettre le nom du serveur devant pour les différencier (c’est aussi ce que fait l’outil xen-create-image). Mais le « _ » peut faire l’affaire.

Jugement personnel. Les VG sur mes machines n’ont pas de nom particulier à avoir, donc celui là convient très bien, sachant que sur cette machine j’ai le vg00 et le vg01. Le premier pour le Dom0 et le second pour les DomU.