OK,
Merci pour le complement d'information,
Est-ce que cela est considere en au-lieu ?
>Selon Patrick Dupre <pd520@???>:
>
>> J'ai regarde sur le web, ce probleme semble connu mais ne pas etre en
>> voie de resolution (sda16 correspondrqit au disque sdb !). Cela parait
>> bien stupide.
>>
>> Pour ma part, je pense aue c'est du a sda (scsi !!, c'est un disque
>> SATA). Je n'ai pas rencontrer ce probleme auparavant sur un disque de
>> portable qui contient plus de partitions ! Probablement parce qu'il est
>> en hda ! Je ne comprends pas cette histoire de hda versus sda. En Fedora
>> 4 mes disques sont vus en hda, en Fedora 7 en sda. Je pense que c'est
>> plus une question de noyau que de distribution. Si quelqu'un a des idees
>> ?
>
>Oui j'ai bien une idée: je te propose de regarder les commandes mknod
>nécessaires pour créer les devices "sdx"
>par exemple sur cette page retournée par Google (que ferait-on sans !)
>http://www.xs4all.nl/~lennartb/installdisk/node8.html
>
> Ce qui confirme qu'un périphérique block SCSI - ou usb-storage, sata...
> bref tout stockage qui utilise l'abstraction SCSI du kernel pour son
> accès - ne peut être accéder au-delà de la 15ème partition. sda == b 8 0
> sdb == b 8 16 sdc == b 8 32 Ce qui ne laisse que 15 positions pour les
> partitions des disques. Les créer ne pose pas de problème à fdisk ou
> autres outils, mais Linux ne saurait pas t'y donner accès - en tout cas
> pas par /dev/sdaX, s'il existe un autre moyen que je ne connais pas.
>
> Donc à moins de patcher le kernel Linux et de modifier un bon paquet
> d'outils qui dépendraient de ces conventions (major/minor device number),
> il y a peu d'espoir d'aller plus loin avec les partitions classiques.
>
> Je t'invite à utiliser LVM, surtout pour un disque aussi grand et avec un
> besoin d'autant de partitions Linux. C'est quand même très sympathique et
> on y prend rapidement goût !
>
>Désolé mais même Linux n'est pas parfait.
>
> Qui aurait pu imaginer qu'un disque puisse être découpé en plus de 15
> partitions ? A une époque, 64 Ko de RAM était une limite inconcevable -
> et malheureusement il traîne encore dans la nature beaucoup de matériel
> et de logiciel qui hérite de ce genre de présupposition. Il y a peu, on
> parlais ici du timestamp de fichier sur FAT qui a une précision de 2
> secondes probablement pour gagner un bit. Tout ce que j'espère, c'est que
> l'on n'en introduise plus actuellement. Mais qui sait, peut-être qu'un
> futur "bug de l'an 2000" m'assurera une retraite dorée dans quelques
> dizaines années ;)
>
>A+
>
--
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Patrick Dupre pd520@???
University of York Department of Chemistry
Heslington YO YO10 5DD United Kingdom
Phone: +44-(0)-1904-434589 Fax: +44-(0)-1904-432516
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
