Forum Linux.général Problème de C/H/S

Posté par  .
Étiquettes : aucune
0
2
juil.
2004
Alors que j'allais tuer ma derniere partition FAT pour en faire une ext3, je lance un petit cfdisk /dev/hdf pour voir avant, et j'obtiens une erreur comme quoi la partition 0 (la seule) dépasse du disque... bon bizarre...

Je lance quand meme un mkfs.ext3 /dev/hdf1 et là, quelques instants plus tard lors du formatage, je me suis retrouvé avec plein de DriveSeek error sur mon TTY... je ne pouvais plus rien faire, j'ai du redémarrer la machine par un bon reset... (manque de bol, je n'ai jamais pris la peine de noter les touches sysrq dans un coin²).

Bon, apres un rebootage, fdisk /dev/hdf et suppression de la partition.
Mais j'en profite pour examiner un peu les information que j'ai sur le disque.

En gros, mon /dev/hdf est le meme disque que le /dev/hda, à savoir un Western Digital 40Go. Le kernel au boot (dmesg) me donne ceci :
hda: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdf: 78165360 sectors (40020 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)

Par contre, fdisk me donne ceci, qui n'a rien a voir dans les deux cas avec ce que dit le kernel :
Disk /dev/hda: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

et

Disk /dev/hdf: 40.0 GB, 40020664320 bytes
16 heads, 63 sectors/track, 77545 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Et clou du spectacle,

lisa:/home/bouil# hdparm -g /dev/hda /dev/hdf

/dev/hda:
geometry = 65535/16/63, sectors = 78165360, start = 0

/dev/hdf:
geometry = 65535/16/63, sectors = 78165360, start = 0

ne me donne pas encore la même chose...

Donc je ne comprends pas très bien le pourquoi ce ces valeurs, j'ai regardé sur le disque si il y était inscrit les valeurs pour C/H/S mais il y a juste indiqué un nombre LBA.

Je précise que je suis en noyau 2.6.6 officiel, que hda est sur le controleur VIA principal de la carte mère et le hdf est branché sur une carte PCI d'extension IDE promise technology :
0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:06.0 Unknown mass storage controller: Promise Technology, Inc. 20268 (rev 02)

Voilà, donc si quelqu'un comprends quelque chose à tout cela, merci de me faire signe... et merci de m'avoir lu jusqu'au bout...
  • # Re:

    Posté par  . Évalué à 3.

    Il se peut que le disque ait été partitionné avec Windows. Dans ce cas il peut aussi utiliser les valeurs C/H/S pour la table de partition. En fait les valeur C/H/S et LBA sont toutes les deux stockées.
    Avec le noyau 2.6 il y a un bug (pas vraiment un bug mais faisons comme si) et il ne retourne pas les bonnes valeurs C/H/S (c-à-d différente avec ce qui est écrit sur le disque (et pas le bios du disque qui est retourné par hdparm)).
    Bref, parfois ça fout le bordel et la situation est très compliquée à comprendre. D'ailleur pour m'y être intéressé j'ai même déjà un peu oublié :-)

    Si tu n'as pas de données sur le disque, écrase la table de partition et le mbr de façon brutale :
    $ dd if=/dev/zero of=/dev/hdf bs=1k count=32
    Puis refais ta table de partition (mais pas sous Windows !).
    Normalement ça doit rouler sans problème. Il n'y aura que les valeurs LBA de stockées et les valeurs C/H/S ne seront jamais utilisées. Pour les C/H/S de fdisk qui sont différents de hdparm, tu peux les ignorer (mais elle doivent correspondre à la taille du disque). Elles sont "virtuelles".
    • [^] # Re: Re:

      Posté par  . Évalué à 1.

      Merci pour l'explication.

      Pour le dd if=/dev/zero of=/dev/hdf bs=1k count=32 je me pose une question.

      J'avais eu recours à cette méthode pour sauver un de mes vieux disque (un 6Go) dont la table de partition avait été bien flinguée et je n'arrivait plus rien à faire. J'avais fait à l'époque un dd if=/dev/zero of=/dev/hdc. Hors les nouveaux disques ont le systeme SMART qui stocke les perfs du disque et s'il voit qu'elle sont sensiblement dégradés, le BIOS affiche une alerte en disant que le disque va lacher et qu'il faut le remplacer... c'est lourd...
      Est ce que ta commande prends en compte cela ?
      • [^] # Re: Re:

        Posté par  . Évalué à 0.

        > Est ce que ta commande prends en compte cela ?
        C'est transparent. Les données smart ne sont pas stockées sur le disque (le support magnétique) mais dans le "bios" du disque. Il n'y a pas plus de problème de faire "dd if=/dev/zero .." qu'un simple "cp".
        dd ne va pas "dégrader" les performances du disque.
        • [^] # Re: Re:

          Posté par  . Évalué à 1.

          Oui, mais alors pourquoi mon 6Go fait des erreurs SMART depuis que j'ai fait ce fameux dd ?

          Ceci dit, j'ai téléchargé l'outil western digital en disquette de boot pour faire un diagnostic de mes 2 disques, et tout a l'air correct. Et d'ailleurs, d'apres lui, la bonne geometrie est 77545/16/63 .... Y a t'il un moyen de réécrire les bonnes valeurs pour le hda ?
          • [^] # Re: Re:

            Posté par  . Évalué à 0.

            > Y a t'il un moyen de réécrire les bonnes valeurs pour le hda ?

            Effacer le disque (avec dd).
            De plus c'est sans intérêt. Linux n'utilise pas C/H/S. Il n'utilise que LBA. Les tables de partition sont maintenant écrite avec LBA.
            Si les valeurs C/H/S ne sont pas écrite sur le disque, Windows utilise que LBA aussi.
            Donc, ne cherche pas à écrire ces valeurs. C'est uniquement une source d'emmerdement.

            > Oui, mais alors pourquoi mon 6Go fait des erreurs SMART depuis que j'ai fait ce fameux dd ?

            Un quart d'heure avant sa mort il était en vie et buvait un verre d'eau.
            C'est l'eau qui l'a tué ?
    • [^] # Re: Re:

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

      Bon en gros ca peut etre ca
      mais juste une chose c'est le dd
      la tu efface les 32 premiers ko....
      alors que la table de partoche est dans le premier ko (avec 512 octet pas 1024;)
      un dd if=/dev/zero of=/dev/hdf bs=512 count=1
      suffit
      meme le bs=512 est inutil vu que c la taille de bloc par defaut de dd
      • [^] # Re: Re:

        Posté par  . Évalué à 0.

        avec 512 octets je ne serais pas étonné qu'il reste des bouts de table de partition.
        32 ko, c'est effectivement trop mais tu es "sûre" du résultat.

Suivre le flux des commentaires

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