Journal Quand les cartes SD se mettent à perdre des cylindres !

Posté par  .
Étiquettes : aucune
13
23
nov.
2011
Etat des lieux

J'ai une carte SD (2 parts: FAT & EXT2) qui s'affiche soudainement sous Android comme "corrompue".
Or, en stockage de masse elle se monte sans problème et les fs sont corrects.

Une analyse avec fdisk montre que les partitions ne sont plus cohérentes au niveau logique et physique. D'ailleurs les partitions sont alignées comme suit:
part1 1 à 887
part2 887 à 1018

En plus de remarquer qu'elles se chevauchent, la carte ne déclare plus que 1017 cylindres au lieu des 1018, 123 têtes au lieu de 128 et 62 secteurs au lieu de 63 (4GB).

Disque /dev/sde: 3973 Mo, 3973054464 octets
123 têtes, 62 secteurs/piste, 1017 cylindres
Unités = cylindres de 7626 * 512 = 3904512 octets

#### Tentative de correction sous fdisk...

Si le FS se monte correctement, c'est que la partition 2 démarre bien à 887.
On tente donc de corriger le problème en détruisant et reconstruisant la table dans fdisk. (1-886, 887-1017)
Dès lors, plus aucun partitionnement ne donne de fs valide, ce qui est étonnant car la partition 1 devrait toujours être alignée :/

Passage sous testdisk...

Partition x86 & analyse rapide & étendue -> RIEN !

Redéfinition géométrie et analyse étendue -> reRIEN !

Passage sous photorec...

Pas de partitions trouvées mais les fichiers sont là.
On pourrait lancer une récup, sauf que j'ai pas envie de me retrouver avec 1000 fichiers et repertoires avec des noms génériques.

Donc on ne doit plus être aligné sur les cylindres d'origine :/

Retour sous testdisk...

Redéfinition géométrie.
Passage en mode expert -> ne plus aligner les recherches sur les cylindres.
Partition x86 & analyse rapide & étendue -> encore RIEN !

Ca devient énervant.

Sans partitionage & analyse rapide -> TROUVE !

Et c'est pas joli :/

Disk /dev/sde - 3974 MB / 3790 MiB - CHS 1018 128 63

     Partition                  Start        End    Size in sectors

   P FAT32                    0   0  2   886  50 30    6759765 [NO NAME]
   P ext3                   886  50 31  1017  57 16     999426

Les partitions se retrouvent dans la zone réservée (MBR & autre) des 63 premiers blocs (devrait être 0 1 1) et donc pas étonnant qu'en cherchant une partition x86 testdisk passe à coté.

testdisk plutôt que photorec

Dès lors que testdisk voit les partitions, les données se récupèrent facilement avec un "P" (afficher les fichiers) et un "c" pour copier chaque répertoire récursivement.
(Photorec n'est donc à utiliser qu'en dernier recours, quand la table des inodes est détruite ou que le fichier à été supprimé).

Firmware ?

La cause de tout ça ?
Un firmware qui n'a pas de blocs de rechange et corrige la géométrie en cas de blocs défectueux ?
Quelqu'un a déjà connu ce genre de corruption ?

  • # ro

    Posté par  (Mastodon) . Évalué à 4.

    Quelqu'un a déjà connu ce genre de corruption ?

    oui, en passant la carte en RO, avec la petite languette physique prévue à cet effet, et en la repassant en RW.

    • [^] # Re: ro

      Posté par  (site web personnel) . Évalué à 6.

      Hein ? La languette en question ne serait pas qu'un bout de plastique sans le moindre lien avec l'électronique de la carte ? Comme les bouts équivalents des cassettes audio ?

      • [^] # Re: ro

        Posté par  (Mastodon) . Évalué à 2.

        Aucune idée de comment cela fonctionne! C'est (c'était) une carte SD banale (marque : Transcend, type : class 6). Et je n'ai pas retenter l'expérience avec une autre, au prix de ces petits machins. Je ne crois pas qu'il s'agisse d'une coïncidence, malgré que cela ne me soit arrivé qu'une fois. L'état de la carte était exactement ce que décrit par le journal.

      • [^] # Re: ro

        Posté par  . Évalué à 2.

        Ouaip.

        P.ex. sur mon appareil photo (et bien d’autres), la targette en question indique juste qu’il faut démarrer sur CHDK, sans gêner en quoi que ce soit l’écriture sur la carte.

  • # Réduction

    Posté par  . Évalué à 5.

    Quelqu'un a déjà connu ce genre de corruption ?

    Ma première clé USB, une 256 Mo USB 2 sans marque de l’époque où elles commençaient juste à être moins chères que deux clés de 128 Mo, est passée un beau jour de 256 Mo à 128 Mo.

    Le nombre de cylindres reporté par fdisk avait diminué de moitié, les fichiers au delà des 128 premiers Mo étaient illisibles, mais pas de problème pour les autres et après repartitionnement et reformatage à 128 Mo, elle fonctionne sans problème.

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Réduction

      Posté par  . Évalué à 2.

      Pareil ici (pour le problème aussi que pour la solution).

      • [^] # Re: Réduction

        Posté par  . Évalué à 4.

        On a les idées un peu plus claires après avoir dormi, et j'ai une solution encore moins compliquée. Suffit d'extraire les partitions et de les ré-écrire alignées.

         dd if=/dev/sde of=/tmp/part1 bs=512 count=6759765 skip=1
         dd if=/dev/sde of=/tmp/part2 bs=512 skip=6759766
        
        
  • # Difficile de savoir

    Posté par  . Évalué à 2.

    Une analyse avec fdisk montre que les partitions ne sont plus cohérentes au niveau logique et physique. D'ailleurs les partitions sont alignées comme suit:
    part1 1 à 887
    part2 887 à 1018

    C’est peut-être seulement que les partitions ne sont pas alignées sur les limites de « cylindres ». Pour peu qu’avec une version de fdisk elle soit vue par défaut avec son partitionnement natif et avec une autre en LBA. Ça pourrait aussi expliquer le nombre de « cylindres » différents (fdisk n’affiche probablement pas un cylindre incomplet).

    En plus de remarquer qu'elles se chevauchent, la carte ne déclare plus que 1017 cylindres au lieu des 1018, 123 têtes au lieu de 128 et 62 secteurs au lieu de 63 (4GB).

    Les clés USB ont quelquefois une géométrie curieuse. Es-tu sûr des valeurs précédentes ? Il faudrait comparer avec une autre clé du même modèle.

    Sans ça, c’est difficile de savoir ce qui est normal et ce qui est lié au problème.

    J'ai une carte SD (2 parts: FAT & EXT2) qui s'affiche soudainement sous Android comme "corrompue".

    Ne serait-ce pas le partitionnement qui était un peu bizarre et que tu l’aurais montée sur un système qui l’aurait mal géré (les partitions FAT sont sensée être alignées sur les cylindres) ?

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Difficile de savoir

      Posté par  . Évalué à 2.

      Le problème c'est que la géométrie "curieuse" confirme qu'il manque 62 blocs: Le bloc 2 du 62 sec/piste correspond au bloc 63 (soit le bloc1 du 1er cylindre) d'un 63 sec/piste.

  • # Pas jouer sur un média mourant

    Posté par  (Mastodon) . Évalué à 6.

    Je te trouve bien téméraire d’avoir attaqué ta carte direct avec fdisk, testdisk et photorec…

    Dans ce genre de cas, je commence toujours par un petit ddrescue :) et je fais une copie de sauvegarde du fichier généré.

    Puis si tu veux avoir ton fichier en tant que périphérique bloc complet :

    sudo modprobe -r loop && sudo modprobe loop max_part=63
    sudo losetup -d /dev/loop0
    sudo losetup /dev/loop0 /chemin/vers/image/disque
    
    

    ensuite, tu peux jouer autant que tu veux sans trop de risques :)
    • [^] # Re: Pas jouer sur un média mourant

      Posté par  . Évalué à 3.

      Je te trouve bien téméraire d’avoir attaqué ta carte direct avec fdisk, testdisk et photorec…

      Contenu pas important, et de tt façons, modifier la table des partitions n'altère en rien les fs.

      Puis si tu veux avoir ton fichier en tant que périphérique bloc complet :

      losetup c'est bien trop long :)

      mount -o loop,ro image mountpoint
      
      
      • [^] # Re: Pas jouer sur un média mourant

        Posté par  . Évalué à 1.

        modifier la table des partitions n'altère en rien les fs

        Sauf si tu mésalignes une partition DOS étendue, qui est une liste chaînée.

      • [^] # Re: Pas jouer sur un média mourant

        Posté par  (Mastodon) . Évalué à 1.

        Le risque n’est pas tant l’erreur humaine que la perte du périphérique. Si jamais il y a un quelconque problème matériel chaque lecture, et pire, chaque écriture risque d’être la dernière I/O sur un bloc voir sur le périphérique entier. Donc si possible, ne faire qu’une lecture…
        J’ai vu plusieurs disques durs et clés USB ne pas survivre à une tentative de récupération directe :)

      • [^] # Re: Pas jouer sur un média mourant

        Posté par  (Mastodon) . Évalué à 1.

        Le mount -o loop, je l’utilise quand j’ai l’image d'une seule partition ou d’un périph sans table de partition, mais c’est moins pratique quand tu dois accéder à la 4eme partition, ou pour faire tourner du fdisk/cfdisk/parted…

  • # There is no cylindre

    Posté par  . Évalué à 1.

    Ta clé USB ne peut pas perdre de cylindres ou changer de géométrie, c'est juste une vue de l'esprit.

    Et ça m'étonnerait que l'adressage CHS soit encore utilisé pour y accéder.

    Et un fdisk ou un parted récent ne s'embête plus non plus avec la notion de cylindres.

    Et pour la perte de données, au moins pour mon SSD, ce sont les puces de NAND flash qui disposent de blocs en réserve et gèrent le remplacement des blocs défectueux.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.