[RESOLU] Clé USB : corruption du système de fichiers

Support Debian
#1

Ave à tous,
.
.

Sous Wheezy, j’achète deux clés USB identiques, de soixante-quatre gigas chacune.

Ensuite, je les formate en ext2, et d’ailleurs on en garde la trace:
.
.

root@CHE:/home/user/Bureau# fdisk /dev/sdb

Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

/dev/sdb: device contains a valid 'ext2' signature, it's strongly recommended to wipe the device by command wipefs(8) if this setup is unexpected to avoid possible collisions.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xa91e3884.

.
.
En revanche je déclare bien une partition /dev/sdb1, puisque sur des clés de cette taille on ne peut pas faire autrement.

Ensuite je mets mes fichiers, à l’identique sur les deux clés.

Quelques mois se passent, je change un fichier de temps en temps.

Arrive Jessie. Pour faire l’upgrade et le dist-upgrade, je retire soigneusement mes deux clés, de manière à ce qu’elles ne gênent pas la mise à jour de Grub.

Je remonte sous Jessie ; je remets mes deux clés (sdb et sdc, mon sdb1 et sdc1 n’existant plus…) sur la machine : impossible de les monter, automatiquement et manuellement.

Après avoir regardé la question as well, il reste deux choses qui m’étonnent.

La première est dans Dmesg:

root@CHE:/home/user/Bureau# dmesg | grep sdc
[   19.685044] sd 7:0:0:0: [sdc] 125038592 512-byte logical blocks: (64.0 GB/59.6 GiB)
[   19.685911] sd 7:0:0:0: [sdc] Write Protect is off
[   19.685913] sd 7:0:0:0: [sdc] Mode Sense: 43 00 00 00
[   19.686664] sd 7:0:0:0: [sdc] No Caching mode page found
[   19.686716] sd 7:0:0:0: [sdc] Assuming drive cache: write through
[   19.692189]  sdc: unknown partition table
[   19.695197] sd 7:0:0:0: [sdc] Attached SCSI removable disk
[ 4836.271646] EXT4-fs (sdc): mounting ext2 file system using the ext4 subsystem
[ 4836.275229] EXT4-fs (sdc): ext4_check_descriptors: Block bitmap for group 384 not in group (block 0)!
[ 4836.275233] EXT4-fs (sdc): group descriptors corrupted!
[ 4903.112565] EXT4-fs (sdc): mounting ext2 file system using the ext4 subsystem
[ 4903.116086] EXT4-fs (sdc): ext4_check_descriptors: Block bitmap for group 384 not in group (block 0)!
[ 4903.116090] EXT4-fs (sdc): group descriptors corrupted!

.
.
Pourquoi EXT4 (qui est le format du disque principal) alors que mes clés sont en ext2 ?
.
.
La seconde, c’est qu’en lançant un fsck, ce dernier me propose de traiter le même bloc (le 384) sur les deux, la sdb et la sdc ; louche, non ?
.
Et enfin je me demande d’où peuvent venir ces corruptions, s’il y en a vraiment, d’autant qu’il y a un upgrade à Jessie dans l’affaire.

Sinon j’ai bien vu qu’on a ce qu’il faut pour réparer, ou je peux tout bonnement recommencer le formatage, mais quand même, cela paraît curieux.

#2

je n’ai rien compris !!

#3

Bien sûr que si. La taille n’a aucune importance.

Par contre ce n’est pas une bonne idée de formater la clé entière sans table de partition puis d’y créer une table de partition, les deux types de méta-données vont coexister et cela risque d’entraîner de la confusion de la part des “monteurs” de volumes automatiques. Avant de passer d’un format sans partition à un format avec ou vice versa, je recommande d’effacer toutes les signatures de méta-données du périphérique avec wipefs.

#4

Merci à toi !

C’est-à-dire que je croyais que l’on pouvait se passer de table de partition, je veux dire s’en passer complètement, ad vitam…

Ok pour wipefs, je me demandais, justement…

A+

#5

Bien sûr on (en tout cas avec GNU/Linux) peut se passer de table de partition et quelle que soit la taille du périphérique, c’est exactement ce que j’ai répondu et l’inverse de ce que tu affirmais dans ton message initial.

Mais je ne le recommande pas, au moins pour les périphériques sur lesquels les OS courants s’attendent à trouver une table de partition, car son absence peut être considérée par un de ces OS comme le signe que le périphérique est vide, surtout quand l’OS ne sait pas lire le format de données utilisé.

Si j’ai bien compris, tu as créé un système de fichiers sur le périphérique entier /dev/sdb, puis une table de partition et une partition /dev/sdb1 sans contenu. Cette configuration est dangereuses car elle peut facilement faire croire que le périphérique est vide, et certains OS “bien intentionnés” pourraient proposer de formater la partition. Au passage, si tu avais fait créé une table de partition GPT (par défaut pour un périphérique de plus de 2 Tio), cela aurait écrasé le début du système de fichiers contenu dans /dev/sdb car contrairement à une table de partition DOS qui n’occupe qu’une partie du premier secteur (non utilisé par le format ext2/3/4), elle occupe en plus plusieurs secteurs (14 par défaut) au début et à la fin du périphérique.

Je me rends compte que je n’avais pas lu entièrement ton message initial, je réponds donc maintenant à d’autres points.

N’existent plus alors que tu les avais créées avec fdisk (et enregistré les changements ?) ou juste vides ?

Le pilote ext4 sait aussi lire les formats ext2 et ext3. Comme il a déjà été chargé pour monter la racine du système, je suppose que le noyau s’en est automatiquent servi pour monter la clé, évitant de charger le pilote ext2.

J’avoue que c’est étonnant. Il faudrait que tu aies effectué les mêmes opérations dans le même ordre sur les deux clés pour que le résultat ait une chance d’être identique.

Avant de débrancher les clés, as-tu démonté proprement leurs systèmes de fichiers ? Sinon, il pouvait rester des opérations d’écriture inachevées, laissant le système de fichiers dans un état incohérent. C’est l’inconvénient d’ext2 : sans journalisation, il n’y a pas moyen de rejouer les opérations inachevées au remontage et on doit parfois faire un fsck pour corriger les incohérences et pouvoir remonter le système de fichiers.

PS : le titre du sujet ne me paraît pas correspondre à ce que tu décris : aucun signe de détérioration physique et encore moins immédiate puisqu’il s’agit d’une corruption du système de fichiers intervenue après plusieurs mois d’utilisation, après les avoir débranchées.

#6

Quand c’est pour donner à quelqu’un (travaux d’impression) je mets la clé en VFAT ; adonc là c’est pour moi, mes sauvegardes en tous genres.

Le faisant très rarement, je fais un peu… ce qui veut bien passer.

En général j’essaie quelque chose comme

mkfs.ext2 /dev/sdb

La plupart du temps ça bloque et, après avoir cherchouillé un peu de droite et de gauche, je tente un:

#mkfs.ext2 /dev/sdb1

qui lui en général passe ; cela ne dépasse guère ce niveau de tribulation heuristique…

Oui, cela paraît vraiment une explication cohérente.

[quote=“PascalHambourg, post:5, topic:71962”]
Il faudrait que tu aies effectué les mêmes opérations dans le même ordre sur les deux clés pour que le résultat ait une chance d’être identique.[/quote]

Précisément, je suis tellement maniaque que cela semble parfaitement possible ; ce sont de gros fichiers (3D par exemle), et je fais cela à l’unité et dans un véritable cérémonial ; je termine par un df sur les deux clés !

Non, je le fais jamais, c’est peut-être la cause en effet ; en revanche débrancher une clé travaillant, je pense que c’est quasi impossible ; enfin c’est toujours pareil, on sait jamais…

OK. Bien écoute merci pour tout cela, qui m’éclaire quand même pas mal, et pour le soin de l’avoir mis ! Sacré boulot quand même… Et puis alors c’est vrai qu’en mode graphique on a moins la tête à monter et démonter, alors qu’en ligne de commande il ne viendrait jamais à l’idée de laisser un périphérique “en souffrance”…

A+

Sergio