SPT : Une alternative au système historique de partitionnement des PC

Posté par  . Modéré par Amaury.
Étiquettes :
0
2
déc.
2004
Technologie
SPT (pour Simple Partition Table) est un système de partitionnement qui a 3 objectifs principaux :
1) être simple. Simple à comprendre, simple à programmer, simple à dépanner (même sans logiciel spécifique)
2) être fiable. Rendre impossible sinon improbable toute corruption accidentelle de la table de partitions
3) pas de partitions étendues. Cet objectif découle des deux premiers : Premièrement, les partitions étendues sont des poupées russes : une partition qui en contient deux autres, une partition utilisable et une nouvelle étendue. Cela rend la liste complète des partitions plus difficile à récupérer car il faut parcourir tous les niveaux d'imbrication des partitions. Deuxièmement, la "survie" d'une partition dépend de la survie de toutes les étendues qui l'englobent, donc une seule corruption à un niveau rend inaccessibles toutes les données de toutes les partitions qu'il contient. Pourquoi changer ?
J'ai récemment eu à récupérer une partition supprimée accidentellement, ce qui m'a donné l'occasion de pester contre les standards établis. Mais plutôt que de ne faire que râler, je me suis lancé un défi : inventer un autre système, et le mettre en oeuvre. SPT en est le résultat.

Pour le moment 2 patchs sont disponibles sur le site officiel, un pour le noyau Linux pour pouvoir utiliser un disque partitionné au format SPT, et un second pour libparted pour permettre de partitionner un disque. Il ne manque qu'un élément pour pourvoir s'affranchir du système actuel : un patch pour un lanceur (« bootloader ») afin de pouvoir démarrer un système d'exploitation sur un disque au format SPT. Un système de migration du format actuel au format SPT est prévu.

Attention : SPT n'est en rien compatible avec le format actuel et empêche donc l'utilisation d'un disque partitionné au format SPT avec un système d'exploitation ne le prenant pas en charge (le disque serait au mieux détecté comme non partitionné). Aucune compatibilité n'est prévue, pour des raisons purement techniques.

Aller plus loin

  • # SPT versus EFI-GPT

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

    bonjour, tout d'abord je suis assez content de voir que des gens pense a changer le system de partition actuellement utilise (de type dos). Ensuite, je m'interoge sur l'utilite de SPT par rapport au systeme de partition EFI-GPT qui est actuellement le systeme de partition utilise sur les machines ia64 (equipees de processeurs itanium2 d'intel). Le systeme EFI-GPT est deja gere par libparted et offre apparement les memes fonctionnalites que SPT (corrigez moi si je me trompe). Quelqu'un a t'il un avis sur l'utilite de SPT par rapport a EFI-GPT ?

    • [^] # Re: SPT versus EFI-GPT

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

      Moui mais le monde des LL à l'origine c'etait surtout pour avoir le choix
      Evidement avoir le choix pour les types de tables de partitions ca va etre joli, mais c'est commes les systemes de fichiers, on doit pouvoir s'en sortir sans trop de probleme.
      Moi personnellement maintenant je me passe largement de table de partition directe et j'utlise LVM.
      Et mon prochain disque dur serait purement du LVM sans table de partition au debut....
      A moins que j'ai un probleme sur le boot manager zut je me disais bien.....
      Enfin bref tout ca pour dire que y a deja des alternatives, et que vouloir refaire un standard
      Ah sinon ce que je dis c'est surtout pour les x86
      Apres pour les ppc y a un autre type de table de partitions et surement d'autre pour d'autres architectures etc etc

      • [^] # Re: SPT versus EFI-GPT

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

        On peut faire ça ? Je croyais que / et /boot ne pouvaient pas être en LVM parceque c'est le boot loader qui a besoin de lire ces partitions et vu la taille d'un boot loader, il aurait du mal à intégrer les fonctionalités de partition dynamique (LVM) en plus de ext2, ext3,...

        • [^] # Re: SPT versus EFI-GPT

          Posté par  . Évalué à 3.

          D’après le guide LVM2 trouvé sur le site de Gentoo, il est possible de créer un noyau avec un initrd contenant tout ce qu’il faut pour avoir la partition racine en LVM CF.
          http://www.the-infinite.org/archive/docs/lvm/howto-boot-off-root-lv(...)

        • [^] # Re: SPT versus EFI-GPT

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

          Oui, on peut le faire, enfin ça fonctionne chez moi. Le /boot peut être n'importe où (j'avais fait un test à la fin de mon disque de 120Go).

          Après, je ne sais pas si c'est souhaitable, mais je me dis qu'en cas de problème un CD de boot pourra gérer le LVM.

        • [^] # Re: SPT versus EFI-GPT

          Posté par  . Évalué à 1.

          Si tu mets le noyau dans un volume logique LVM alors il faut utiliser LILO patché avec le device-mapper (ok en Debian testing/sid) pour pouvoir booter.

          Avec GRUB point de salut, il ne «comprends» pas encore le LVM.

    • [^] # Re: SPT versus EFI-GPT

      Posté par  . Évalué à 10.

      Le format EFI ne satisfait pas mon premier critère qui est la simplicité.

      Mon idée première est d'avoir un système de partitons à toute épreuve, secourable avec hexedit + la description la plus courte, précise et compréhensible possible de la structure + de quoi convertir un nombre décimal en hexadécimal.

      Mais je conçois sans problèmes que l'ont puise espérer d'un système de partitions plus que ce que SPT offre.

      • [^] # Re: SPT versus EFI-GPT

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

        Moui effectivement vu comme ca.....
        Apres est-ce que imprimer sa table de partition (fdisk -l > /dev/lp0)
        Et la restorer a la main avec les blocs, cylindres etc n'est pas plus simple?
        Enfin les deux sont longs c'est vrai...
        Mais au moins fdisk est (tres) relativement clair.
        Quoique je n'ai pas vu le format SPT
        À voir
        Par contre l'interet que je pourais voir c'est la suppression des partitions étendues.
        Sinon être fiable t"entends quoi par la?
        Pouvoir se corriger facilement?
        Ou bien être peu sensible à la casse (bien que je vois mal comment c'est possible peut être les données répliquées?)

        • [^] # Re: SPT versus EFI-GPT

          Posté par  . Évalué à 4.

          Et bien, niveau fiabilité, déjà SPT ne souffre pas du problème des partitions étendues, définies dans une liste chainée, aussi solide que son maillon le plus faible comme chacun le sait ;).

          D'autre part, l'alignement des données sur des blocs de 16 octets assure une lisibilité certaine avec des softs comme hexedit.

        • [^] # Sauvegarde de table de partitions

          Posté par  . Évalué à 10.

          Apres est-ce que imprimer sa table de partition (fdisk -l > /dev/lp0)
          Et la restorer a la main avec les blocs, cylindres etc n'est pas plus simple?

          sfdisk est plus précis et peut produire une sortie qu'il acceptera comme entrée :
          sfdisk -d /dev/hda | sed -e 's/^N°/#/' > /mnt/floppy/hda.sfdisk sauvegardera la table, et
          sfdisk /dev/hda < /mnt/floppy/hda.sfdisk la restaurera (enfin si la disquette est lisible...).

          L'appel à sed, c'est pour remettre le dièse de commentaire sur la première ligne à la place du "N°" par lequel il a été finement traduit en français, en tout cas sur la version que j'ai...

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

        • [^] # Re: SPT versus EFI-GPT

          Posté par  . Évalué à 6.

          C'est toujours une fois les données perdues qu'on trouve les idées qui auraient permis d'éviter le massacre. Dans le sens où je ne connais personne qui imprime ses tables de partitions. Et puisque pour SPT je suis parti d'une feuile blanche et de mon expérience de la table de partitions DOS, pourquoi ne pas simplifier le problème à la racine ?

          Pour ce qui est de [c]fdisk. Les outils de partitionnement ou de lecture des informations pour SPT sont encore à inventer.
          Peut-être un utilitaire pour imprimer à la chaîne les tables de partitions des disques d'un serveur. Ou peut être ajouter un champ pour savoir si une table a été sauvée ou non depuis sa dernière modification, et un petit rappel au boot si ça n'a pas été fait.

          Pour plus de détails, je conseille de visiter le site officiel, j'y ai détaillé autant qu'il m'a parut nécessaire chaque point de ce système et les raisons qui ont conduit à chaque choix.

        • [^] # Re: SPT versus EFI-GPT

          Posté par  . Évalué à 2.

          C'est ça à quoi je pensais, les données répliquées, ou avec un crc avec correction, ou qqch du genre.
          Car même si on a moins de risque en la manipulant, on peut aussi se retrouver avec un disque inutilisable meme si seuls les quelques premier blocks sont ilisibles...

      • [^] # Re: SPT versus EFI-GPT

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

        J'ai parcouru avec grand interêt ton document, et j'ai bien apprécié. Je pense même tenter d'écrire un outil d'édition pour ces hypothétiques tables de partitions (je suis un ncursiste acharné :). Seulement, voilà, ma nature paranoïaque m'emmène à suggérer l'ajout d'un champ de contrôle: une petite crc16 sur les données me remplirait d'aise.

    • [^] # Re: SPT versus EFI-GPT

      Posté par  . Évalué à -4.

      Est-ce que SPT utiliser SPT fait disparaître les accents?

    • [^] # Re: SPT versus EFI-GPT

      Posté par  . Évalué à 3.

      J'ajoute juste que GPT n'utilise plus non plus de partitions etendues. Le nombre de partitions est limite a 128, mais j'ai cru comprendre qu'on pouvait tweaker le systeme pour en avoir plus.

      D'ailleurs, EFI-GPT a, a l'origine, ete concu pour etre utilise sur x86 en plus de l'ia64. On peut partitionner un disque en GPT avec parted, et si j'ai bonne memoire, je crois que windows 2000 savait y acceder. EFI a egalement pour but a terme de remplacer le BIOS sur les PC.

  • # Intéressant.

    Posté par  . Évalué à 4.

    C’est sûr qu’une bonne remise à plat du système de partitionnement simplifierai grandement la vie, le schéma actuel n’a pas beaucoup bougé depuis l’apparition de l’IBM XT et de DOS 3.2.

    • [^] # Re: Intéressant.

      Posté par  . Évalué à 4.

      La plus vieille table de partition référencée dans l'historique de MS-DOS que j'ai trouvé date de la version 2.0, c'est à dire 1983.
      La table permettait alors de n'avoir qu'une seule partition de 15Mo. (mais à mon avis peu de gens ont eu un disque de cette capacité à l'époque...)

  • # Est-ce vraiment utile ?

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

    Linux gère déjà 22 formats de partitions.
    Est-ce bien utile d'en inventer un de plus, ni a t'il donc aucun schema de partitionnement qui répond déjà à la problèmatique ?

    config ACORN_PARTITION
    config ACORN_PARTITION_CUMANA
    config ACORN_PARTITION_EESOX
    config ACORN_PARTITION_ICS
    config ACORN_PARTITION_ADFS
    config ACORN_PARTITION_POWERTEC
    config ACORN_PARTITION_RISCIX
    config OSF_PARTITION
    config AMIGA_PARTITION
    config ATARI_PARTITION
    config IBM_PARTITION
    config MAC_PARTITION
    config MSDOS_PARTITION
    config BSD_DISKLABEL
    config MINIX_SUBPARTITION
    config SOLARIS_X86_PARTITION
    config UNIXWARE_DISKLABEL
    config LDM_PARTITION
    config SGI_PARTITION
    config ULTRIX_PARTITION
    config SUN_PARTITION
    config EFI_PARTITION

    • [^] # Re: Est-ce vraiment utile ?

      Posté par  . Évalué à 10.

      Avoir une solution simple et indépendante ?

      (Notamment pour éviter de trimballer les casseroles des autres systèmes :
      - brevets ;
      - erreurs ou défauts ;
      - « propriétarité » (pourquoi qu'on choisit celui de X alors que le mien il est aussi bien ?)
      etc.)

      • [^] # Re: Est-ce vraiment utile ?

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

        Faire une solution de plus, pourquoi pas. Mais pour avoir quelques chances de succès, il faut faire ce que Hans Reiser a fait avec les systèmes de fichiers.
        C'est après avoir étudié tous les systèmes de fichiers que Hans Reiser a trouvé qu'il n'y en avait aucun de bien et a décidé d'en faire un de plus.
        C'est parce que reiserfs avait beaucoup d'avantages qu'il a pu percer.

        Un nouveau système de partitionnement ne peut réussir que si il suit le même parcours.

      • [^] # Re: Est-ce vraiment utile ?

        Posté par  . Évalué à 2.

        "Independante" OK, toi tu souffres d'un gros syndrome NIH..

        Pour ce qui est de la simplicité, as-tu essayé les autres schémas avant de dire qu'ils ne sont pas simples?

    • [^] # Re: Est-ce vraiment utile ?

      Posté par  . Évalué à 4.

      J'imaginais même pas qu'on pouvait changer de type de table de partition !

      On peut utiliser un de ceux la sur une architecture x86 ?

      • [^] # Re: Est-ce vraiment utile ?

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

        Ben y a deux problemes:
        -Y a peut-être du code spécifique à l'architecture qui fait que c'est incompilable
        -Faut un boot manager qui le supporte pour ton architecture (oui un boot manager est plus ou moins specifique a une architecture)

      • [^] # Re: Est-ce vraiment utile ?

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

        > On peut utiliser un de ceux la sur une architecture x86 ?

        On peut tous les utiliser sur n'imorte qu'elle architecture.

        La seule limitation concerne le disque d'amorçage, il faut que le bootloader connaisse le schema de partionnement, et sur x86, les bootloader n'en connaisse qu'un faible nombre.

        Pour tous les autres disques, on peut utiliser ce qu'on veut, du moins ce qui est adapté aux disques durs actuels de forte capacité.

  • # Incompatible ?

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

    Ce qui me chagrine, c'est qu'il n'y a pas comme objectif d'avoir un driver/bootloader/machin truc pour le faire marcher sous windows. C'est vraiment impossible ou c'est juste trop complique a faire pour l'instant ?

    Quand je vois des programmes qui sous windows, creent des lecteurs de DVD virtuels, je me dis que ca doit pas etre impossible au moins de rendre les partitions visibles, et au mieux d'y installer windows.

    Certe, on est sur linuxfr mais l'interet d'avoir plusieurs partitions, c'est bien d'avoir plusieurs OS disponibles.

    • [^] # Re: Incompatible ?

      Posté par  . Évalué à 3.

      Tu n'es pas obligé d'avoir Windows sur ta partition de démarrage. Il te suffit d'avoir Lilo ou grub, qui se chargeront de lancer Windows à partir de là où il est.

      • [^] # Re: Incompatible ?

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

        et comment qu'il fait le windows pour trouver ses propres disques avec ça ? comment il sait que la table des partitions qu'il va scanner n'existe tout simplement plus ?

        • [^] # Re: Incompatible ?

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

          Il est grand, maintenant, il se débrouille.

          Ce sera juste un peu chiant si les lettres des lecteurs sont mélangées, mais suivant la version, un coup de "Gestion des Disques" et ça devrait le faire, non ?

          C'est pas prévu ? C'est pas du déplug & play ?

          • [^] # Re: Incompatible ?

            Posté par  . Évalué à 0.

            plug and pray, nuance !
            oups, j'ai oublié le copyright "Eglise Saint-Dodows, Arizona".
            Envoyez vos dons épinglés aux rapports de bugs et ... priez ...
            Windowz Rulez !

    • [^] # Re: Incompatible ?

      Posté par  . Évalué à 10.

      mais l'interet d'avoir plusieurs partitions, c'est bien d'avoir plusieurs OS disponibles.

      Non. Meme avec un seul OS, il est toujours bon de partitionner son disque, ne serait-ce que pour avoir une partition donnees separee du systeme. En cas de crash du systeme, on peut toujours recuperer sa partition data.

      Et puis on peut aussi faire une partition pour le spool de mail (dans le cas d'un serveur), une pour le repertoire /etc (pour ne pas perdre sa configuration en cas de crash ou de reinstallation), ...

      Bref, il y a tout plein de cas ou le paratitionnement est tres pratique, sans forcement utiliser plusieurs OS.

    • [^] # Re: Incompatible ?

      Posté par  . Évalué à 7.

      Certe, on est sur linuxfr mais l'interet d'avoir plusieurs partitions, c'est bien d'avoir plusieurs OS disponibles.

      Je suis d'accord avec le reste de ton commentaire mais pas avec cette phrase-là : l'intérêt d'avoir plusieurs partitions, c'est de ne pas mettre tous tes ½ufs dans le même panier.
      En clair, tu fais des partitions dont la taille, le format et les options de montage sont dépendantes et adaptées aux données qui y figurent et à ce que tu fais avec ces données.

      • [^] # Re: Incompatible ?

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

        Je pense qu une petite lecture de http://www.doublehp.org/bien_organiser_ses_partitions.txt(...) serait utile a certains ... ( ce texte a deja ete propose en tip. mais les comme les modos mettent plus de 2 semaines a les moderer ... )

        • [^] # Re: Incompatible ?

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

          mettre le swap à la fin, c'est pas top niveau vitesse. AMHA, il faut le mettre en deuxième partition, juste après /boot.

          Voilà ce que j'ai sur mon PC :

          /dev/md1 /boot
          /dev/md2 swap
          /dev/md5 /
          /dev/md6 /usr
          /dev/md7 /var
          /dev/md8 /opt
          /dev/md9 /home

          • [^] # Re: Incompatible ?

            Posté par  . Évalué à 4.

            Il peut aussi être intéressant de séparer /var et /var/cache (sur la Debian en tout cas) car ce qui prends de la place dans /var est de deux nature:
            - les logs (donc partition /var)
            - le cache de apt-get (/var/cache)

            Comme ces deux risquent d'avoir une certaine tendance à grossir vite pour une raison où une autre, c'est intéressant de les séparer pour éviter qu'ils ne se marchent dessus.

          • [^] # Re: Incompatible ?

            Posté par  . Évalué à 3.

            La vitesse linéaire du disque n'est pas le seul paramêtre à prendre en compte. Tu as aussi intéret à avoir le swap pas trop loin de tes partitions les plus sollicitées, pour limiter le déplacement des têtes de lecture.

    • [^] # Re: Incompatible ?

      Posté par  . Évalué à 2.

      Pour le moment ce n'est pas prévu.
      Mais comme le bootloader de windows est lancé par lilo/grub/..., je crains que le changement n'ait besoin d'être plus en profondeur, et au delà de ce que l'on peut modifier (cette remarque n'est valable que pour le disque sur lequel est windows).
      Le driver peut devenir utile pour que windows puisse lire un disque partitionné avec SPT.

      • [^] # Re: Incompatible ?

        Posté par  . Évalué à 2.

        Dansl'article, par "aucune compatibilité n'est prévue", j'entend une compatibilité "par le bas", c'est à dire que la table de partition soit compatible. Je n'exclu bien entendu pas l'écriture d'un driver pour que le système d'exploitation prene en charge SPT.

    • [^] # Re: Incompatible ?

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

      Certe, on est sur linuxfr mais l'interet d'avoir plusieurs partitions, c'est bien d'avoir plusieurs OS disponibles.

      Moi j'ai des partitions séparées pour / /boot /usr
      /etc /home /usr/local et /tmp

      /boot et /usr sont en read only, comme ça y'a moins de risque de casser quelque chose par erreur. Je les remontes en rw quand je fais une maj.

      /etc /usr/local et /home me permettent de ne rien perdre en cas de réinstallation.

      et /tmp séparé me permet de ne pas pourrir mon disque entier uniquement avec des fichiers temporaires.

      (sur un serveur, j'ai aussi un /var séparé)

      • [^] # Re: Incompatible ?

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

        pour ceux qui se poseraient la question du boot avec un /etc séparé, il suffit de garder un repertoire /etc dans sa partition /root.

        Je synchronise les 2 quand je fais un changement (que je teste avant), ça me permet d'avoir toujours un /etc de secours et quand j'upgrade, je peux "merger" les fichiers tranquillement en les comparant.

      • [^] # Re: Incompatible ?

        Posté par  . Évalué à 2.

        Comment tu fais pour avoir un /etc en readonly ?

        Tu le repasses en RW à chaque fois que tu monte un CD, une disquette, ou une clef USB???

        Pour moi, il faut bien que mtab soit mis à jour.

        • [^] # Re: Incompatible ?

          Posté par  . Évalué à 2.

          # rm /etc/mtab && ln -s /proc/mounts /etc/mtab

        • [^] # Re: Incompatible ?

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

          "boot et /usr sont en read only"
          Il n'a jamais dit que son /etc était en read-only :)

          Yth.

          • [^] # Re: Incompatible ?

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

            exactement :)

          • [^] # Re: Incompatible ?

            Posté par  . Évalué à 2.

            Oups, désolé, vraiment.

            Pour ma défense cette satané de sinusite ne me laisse pas les idées très claires.

            Encore désolé monsieur PsychoFox :-)

        • [^] # Re: Incompatible ?

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

          Comment tu fais pour avoir un /etc en readonly ?

          comme explique plus bas ... ton /etc doit etre sur la meme partoche que /sbit et / ... la solution est donc d avoir un / es RO ... mais alors il devient obligatoire d avoir un /tmp separe ... mais c est jouable si tu y vaois un interret.

  • # Et le RAID ?

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

    D'après la description de SPT, le type de partition est supprimé. Comment fait alors le noyau pour détecter les partitions en RAID logiciel ?

    Il semble donc qu'avec un tel système on puisse pas monter les partitions RAID automatiquement et donc booter sur un tel système.

    • [^] # Re: Et le RAID ?

      Posté par  . Évalué à 1.

      N'y a-t-il réellement aucun moyen de détecter le format d'une partition par son contenu ?
      Je supose qu'en début de partitions liées entre elles en raid logiciel il y a le descriptif d'où trouver l'autre partition, pour que les 2 bonnes partitons soient associées. Dans ce cas, il y a très probablement moyen de reconnaître cette structure.

      Si ce n'est pas le cas, pourquoi ne pas rajouter ce champ.
      Comme SPT n'est utilisé nulle part pour le moment, on peut le modifier sans problèmes. Et une fois une version basique mise au point, les variantes seront distinguées par leur n° de version.

      • [^] # Re: Et le RAID ?

        Posté par  . Évalué à 3.

        si, elles ont une signature en général, et mount va la rechercher, soit pour "deviner" justement le type (montage automatique), soit pour refuser de monter une partition du mauvais type.

  • # Limitations

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

    Hum, moi ce qui me gêne, c'est la limitation de 31 partitions. Ca fait 4 partitions pour 8 distributions différentes (par exemple). Il faudrait pouvoir changer cette limite, voir même prévoir un système illimité.

    De plus

    Haypo

    • [^] # Re: Limitations

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

      Je suis d accord : Linux integre par default que 20 devices par disque, mais est etendable a 64 ... et j ai moi meme deja attend 25 partitions sur un disque . Alors 31 comme deadline, c est limite. D ailleurs pourquoi 31 et pas 255 ?

      Ca fait 4 partitions pour 8 distributions différentes

      hmmm / /home /usr /usr/src /var /tmp ... ca fait 6 chez moi. Sur un system bien reparti, la partition du / doit tenire dans 100Mo.

      ( Reminder : ne jamais mettre /sbin et /etc sur des partitions separees )

      • [^] # Re: Limitations

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

        Sauf que deja, ton /home tu le gardera surement pour plusieurs distributions

        Reminder : ne jamais mettre /sbin et /etc sur des partitions separees )
        Ou plutot toujours avoir /sbin et /etc sur le /
        Sinon comment ton noyau appele-t-il /sbin/init au démarrage sinon ?

        • [^] # Re: Limitations

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

          Sinon comment ton noyau appele-t-il /sbin/init au démarrage sinon ?

          un ami a faut de l ecxes de zele sur fdisk ... et as eu le probleme :/

          Solution : mounter sbin dans /mnt/tmp, et copier juste mount et init dans la partition du / ...

          bon ok c est vraiment gruik ..... /me -> [___]

          • [^] # Re: Limitations

            Posté par  . Évalué à 1.

            Il y a le initrd, aussi. Au départ, il est conçu pour ce genre de problèmes de bootstrap, quand même.

        • [^] # Re: Limitations

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

          Salut, homonyme.

          Pas tout à fait d'accord, pour le /home.

          Par exemple, si tu as des versions différentes des logiciels que tu utilises suivant la distrib, ça peut mal se passer si le format des fichiers de config est différents (au hasard, une Gentoo qui vient d'émerger et une Debian de y-a-2 ans, c'est pas pareil...)(Warning ! Troll Inside !).

          Sinon, ça risque pas de poser problème, si le UserId et le GroupId sont différents ?

          'Vaut mieux partager un sous-répertoire que le /home, non ? (genre avec un mount -bind bien senti).

          Wilfried "Will" Pineau

          • [^] # Re: Limitations

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

            Par exemple, si tu as des versions différentes des logiciels que tu utilises suivant la distrib, ça peut mal se passer si le format des fichiers de config est différents (au hasard, une Gentoo qui vient d'émerger et une Debian de y-a-2 ans, c'est pas pareil...)(Warning ! Troll Inside !).

            Dans ce cas, entièrement d'accord! Disons que je parlais d'un /home au sens large du terme, en respectant le FHS, c'est à dire : une partition pour les données de l'utilisateur. Si tu veux l'appeler /data, c'est pareil :)

            Sinon, ça risque pas de poser problème, si le UserId et le GroupId sont différents ?

            Si c'est ta propre machine, c'est loin d'être impossible de conserver les mêmes uid et gid pour toutes tes distributions ... ou alors le type est neuneu et n'y connait rien à GNU/Linux, dans un tel cas pourquoi utilise-t-il plusieurs distrib' ? :p

            'Vaut mieux partager un sous-répertoire que le /home, non ? (genre avec un mount -bind bien senti).

            Cf mon 1er paragraphe.

            • [^] # Re: Limitations

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

              Si c'est ta propre machine, c'est loin d'être impossible de conserver les mêmes uid et gid pour toutes tes distributions ... ou alors le type est neuneu et n'y connait rien à GNU/Linux, dans un tel cas pourquoi utilise-t-il plusieurs distrib' ? :p
              Pour trouver celle qui lui convient ?

              On est d'accord.

    • [^] # Re: Limitations

      Posté par  . Évalué à 4.

      Pas de problème, ça peut être étendu.
      Il y a deux solutions, soit on augmente la taille de la liste des partitions, soit on diminue la taille de chaque entrée. Si on considère que l'on n'auras jamais besoin de plus d'une certaine taille (avec 2^64 j'ai pris une marge considérable, c'est 2^32 dans la table dos, ce qui permet déjà de gérer un disque de 2To avec des blocs de 512o) on augmente proportionellement le nombre de partitions maximal.

      Je pense qu'il va faloir que je mette en place un forum sur le site officiel pour y rescencer toutes les idées et permettre d'en proposer d'autres de façon structurée.

      • [^] # Re: Limitations

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

        Gaffe aux limites qui paraissent très larges pour le moment...


        Un certain Bill G commercialisait en son temps un 'OS' avec une limite assez chi**** vers les 640Ko pour la mémoire vive, et vers les 32Mo pour les disques durs...

        A+

        Laurent.

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

        • [^] # Re: Limitations

          Posté par  . Évalué à 2.

          Et un certain Linus T n'a pas concu son OS pour fonctionner sur autre chose qu'un PC x386 (parce qu'il n'avait que ca pour developper)...

        • [^] # Re: Limitations

          Posté par  . Évalué à 1.

          Il n'avait pas le choix. Les processeurs 8088 et 8086 ne pouvaient pas adresser plus de 640 Ko et ne possédaient aucune MMU. De plus, en 81, le commun des mortels ne pouvait pas s'offrir l'équivalent des possibilités d'un VAX (le 80386 n'existait pas encore).

          • [^] # Re: Limitations

            Posté par  . Évalué à 2.

            Tttt, si le DOS avait mis ses données au début et non pas a la fin, il n'y aurait pas eu trop de probleme pour étendre la taille mémoire utilisable lorsque les CPU en aurait la possibilité.

            Donc c'est aussi un manque de prévoyance sur le long terme..

      • [^] # Re: Limitations

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

        Pas de problème, ça peut être étendu.
        Il y a deux solutions, soit on augmente la taille de la liste des partitions, soit on diminue la taille de chaque entrée.

        Je n'ai rien vu de tel dans les spécifications, ou alors j'ai mal lu. Je pense que le plus raisonnable serait de permettre d'avoir plus d'entrée plutôt que de diminuer leur taille.

        Par contre, je suppose que cette limite doit être fixée une fois pour toute, sinon il faut grignoter le début de la première partition primaire, ou bien ? Le plus raisonnable serait de permettre au moins 100 partitions (faut voir large) par défaut : ce qui fait à peu près 4 secteurs par tables à peu près (selon mon calcul de tête). Après, on pourrait en faire plus (ou moins ?) lors de la création des tables. 8 secteurs de nos jours jours ... je ne crois pas vraiment que ça fait beaucoup (sur un disque de 250 Go par exemple).

        L'utilisateur de liste chaînée est si gênante ? Ok qu'on peut faire plus de connerie avec ça, mais c'est plus souple ... J'utilise des listes chaînes tous les jours en copiant des fichiers sous ext3, et ça ne m'a jamais planté à la gueule :-)

        C'est tellement chiant ces limites. Dernières en tête : sur une architecture 32 bits, on ne peut accéder à plus de 32 bits par processus. Sous Windows, pendant longtemps, on ne pouvait pas faire de fichier de plus de 2 Go (embêtant pour l'enregistrement de vidéo brute non compressée) ... hum, je pense que c'était pareil sous Linux. Ne pas pouvoir faire plus de 4 partitions primaires. J'ai appris ça le jour où j'en tenté d'en créer une 5e (damned !). etc.

        @+ Haypo

        • [^] # Re: Limitations

          Posté par  . Évalué à 3.

          Je n'ai rien vu de tel dans les spécifications, ou alors j'ai mal lu.
          J'entend par là que comme SPT n'est pour le moment utilisé nulle part, ça peut être modifié.

          Par contre, je suppose que cette limite doit être fixée une fois pour toute
          Ca peut être fait à des valeurs différentes pour plusieurs versions. Par exemple, une variante pour systèmes embarqués avec des partitions adressées sur 4 octets et une table sur un secteur, puis une autre variante pour gros serveurs très fragmentés avec une table sur plusieurs blocs...
          A partir du moment ou chaque variante s'attribue un numéro de version spécifique, elle peut définir un nouveau format. Il ne faudra conserver que la magic string et le numéro de version, la suite des champs étant lue en fonction du numéro de version.

          L'utilisation de liste chaînée est si gênante ?
          Je en l'ai pas implémentée pour me concentrer sur la première version, et parce qu'elle revient au principe des partitions étendues (la force d'une chaîne, ... comme l'a dit arachne plus haut). Mais à l'origine, il aurait dû y avoir quelque chose comme ça :
          Disque :
          1) bootloader
          2) partitions chaînées
          Partition chaînée :
          1) bloc décrivant la partition
          2) Partition proprement dit
          Avec distinctoin sur la magic string (SPTc par exemple)
          Cela pourait convenir à un système de sauvegarde où l'écriture se ferait en une fois.

  • # Et le BIOS ?

    Posté par  . Évalué à 3.

    Une question bête : n'est-il pas nécessaire que le Bios sache gérer la table de partition pour lancer un OS ou un boot loader ?

    Parce que dans ce cas, la solution dépend du bon vouloir des fabriquants de cartes mères et de Bios.

    A part ça, c'est une bonne idée, j'ai moi même compris récemment, lors d'un partitionnement, le bordel des partitions étendues et les limites héritées des début du PC (4 partitons principales maximum par exemple).

    • [^] # Re: Et le BIOS ?

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

      Non ... le BIOS se contente de lire les 512 premiers octets du disque, verifier que les 2 derniers sont egaux a une constante que j ai oubliee, charge les 510 premier en RAM, en opere un saut au code RAM.

      La table de partition ne commence qu au 513e octet ( ou peut etre plus loin ... le principale etant que tu comprenne que les partitions sont placees APRES ).

      Une fois ton bootloader charge, c est a lui de se debrouiller pour lire les partitions .

      • [^] # Re: Et le BIOS ?

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

        pourtant mon bios il me propose de booter C:, D:, E: .. pas que "disque1" et "disque2" il semble qu'il soit capable de lire les partitions et lancer la partition désignée au lieu du MBR

        • [^] # Re: Et le BIOS ?

          Posté par  . Évalué à 1.

          J'ai eu un BIOS qui disait ça, mais pour lui C: était le premier disque dur, D: le premier lecteur SCSI et E: le premier lecteur IDE ATAPI -_-°. Ça n'avait aucun rapport avec les partitions, ni même avec les notations windows.

          Mais peu importe. En effet, on peut tout-à-fait concevoir des BIOS "évolués" qui interprètent la table des partitions et bootent une partition suivant le standard actuellement le plus répendu. On voit ce genre de monstres sur des portables. Mais tout ça, ce n'est pas en accord avec le comportement standard qu'on est en droit d'attendre d'un BIOS. Normalement, pour tenter de booter sur un disque dur (booter sur le premier disque dur IDE étant généralement appelé "C"), le BIOS vérifie le MBR de ce disque et le charge s'il est marqué bootable, point barre. Je parle bien sûr du cas des PC.

          Pas mal de gens travaillent à changer ce standard, mais aucun n'est encore "officiel." Pas que je sache, en tout cas.

      • [^] # Re: Et le BIOS ?

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

        "charge les 510 premier en RAM, en opere un saut au code RAM."

        Non ... il charge les 446 premiers en RAM.

        "La table de partition ne commence qu au 513e octet ( ou peut etre plus loin ... le principale etant que tu comprenne que les partitions sont placees APRES )."

        Non ... elle commence au 446e octet, elle fait 4 * 16 = 64 octets. Enfin il y a le code sur 2 octets.

    • [^] # Re: Et le BIOS ?

      Posté par  . Évalué à 1.

      Je n'ai pas encore abbordé la question du bootloader, mais j'ai lu (je ne retrouves plus où :s ) que le bios se contentait de charger le premier bloc en ram et de lancer l'execution dessus. Si cela est confirmé, la souplesse est complète.

      • [^] # Re: Et le BIOS ?

        Posté par  . Évalué à 2.

        heu il faut quand mem savoir que le code du bootloader est tres petit, donc il faut que l'implementation puisse etre facilement codable dans le mbr, sinon meme si l'implementation est tres jolie ca ne servira a rien...

        Apres tu as choisit de virer les infos sur le CHS dans le descripteur de partition, je pense que tu vas t'amuser dans le MBR pour les reconvertir dans un format comprehensible par le bios...

        Bref avant de regarder les implementation au niveau noyeau et des outils de partitionnement il faut construire les specs en partant du debut, ie du MBR...

        • [^] # Re: Et le BIOS ?

          Posté par  . Évalué à 2.

          > heu il faut quand mem savoir que le code du bootloader est tres petit, donc il faut que l'implementation puisse etre facilement codable dans le mbr, sinon meme si l'implementation est tres jolie ca ne servira a rien...

          Je pense que ça ne change rien à lilo ou grub, dont la première action est d'aller chercher le reste d'eux-mêmes à un emplacement fixe du disque dur (ou d'un autre), emplacement qui a été défini lors de leur installation sur le MBR.

          • [^] # Re: Et le BIOS ?

            Posté par  . Évalué à 1.

            Et qui est complètement indépendant du partitionnement du disque, parce qu'adressé en cylindres et secteur (adressage physique, c-à-d bas niveau, sur le disque).

          • [^] # Re: Et le BIOS ?

            Posté par  . Évalué à 1.

            oui et non.

            LILO contient la liste des blocs contenant le noyau à lire donc vrai.

            GRUB «monte» et parcours le système de fichiers donc faux.

            cf mon commentaire plus haut sur LVM: ça marche avec LILO parce qu'il est «bête» et ne stocke que les blocs et ça ne fonctionne pas avec GRUB parce qu'il est trop «intelligent» et veut parcourir le système de fichiers.

            • [^] # Re: Et le BIOS ?

              Posté par  . Évalué à 1.

              Oui et non de nouveaux.

              Avec grub, ça ne marcherait pas "tel quel", il faudrait lui ajouter un mécanisme de détection de SPT et la gestion de ce système de partitionnement pour que ça marche. C'est parfaitement vrai.

              Mais on a toute la place qu'on veut pour ajouter ces fonctions, la taille du MBR n'est pas une limite. C'est à cette question que je répondais.

            • [^] # Re: Et le BIOS ?

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

              -1- grub accede au stage1 comme lilo accede au noyeau : acces via CHS

              -2- pour acceder au reste de sa conf ( l arres dynamique ), li stage1 contient un driver pour le le partitionnement du dur : si l auteur de STP a pu ecrire un driver pour Linux, il n aura pas de mal a re-ecrire le meme driver pour grub.

              • [^] # Re: Et le BIOS ?

                Posté par  . Évalué à 1.

                En fait, tu parles du stage2, là. Le stage1, c'est ce qu'on met dans le MBR, éventuellement mixé à/accompagné d'un stage1.5.

        • [^] # Re: Et le BIOS ?

          Posté par  . Évalué à 2.

          le code du bootloader est tres petit
          Justement, je peux augmenter l'espace libre avant la table de partitions, pour permettre un plus gros bootloader. Avant de fixer une taille, j'attend d'en savoir plus sur la place demandée par grub pour tenir entièrement en un morceau.

          Les informations CHS sont à ma conaissance ignorées, puisqu'elles sont dépassées à partir de 8Go. Il se peut par contre que d'anciens BIOS ne sachent que "parler" CHS, dans quel cas il faudra effectivement faire une conversion.

          • [^] # Re: Et le BIOS ?

            Posté par  . Évalué à 2.

            autant pour moi.

            D'apres ce que j'ai vu pour grub :
            -y a le stage1 de 512o (MBR)
            -le stage1.5 est ensuite charge (~10Ko), le code est specifique au systeme de fichier et permet d'acceder au stage2. (je pense qu'il a la notion de partition)
            -le stage2 de 100ko sur le fs.

          • [^] # Re: Et le BIOS ?

            Posté par  . Évalué à 3.

            Justement, je peux augmenter l'espace libre avant la table de partitions, pour permettre un plus gros bootloader. Avant de fixer une taille, j'attend d'en savoir plus sur la place demandée par grub pour tenir entièrement en un morceau.

            Je me posais la question du booloader récemment (je trouve lilo tristounet, grub nécessite un patch pour gérer un clavier azerty et parler français ..). Ne serait-il pas intéressant d'intégrer à ce niveau (ou alors directement dans le BIOS) un boolaoder plus complet, et surtout, configurable soit depuis les OS (Windows, Linux, BSD ...) ou depuis le bootlader lui même (comme le BIOS se configure depuis ... le Bios).

            Y'a aussi des bootloader comme Xosl qui semblent intéressant, mais qui s'installent sur leur propre partition.

            Je ne sais pas quel est le meilleur endroit (Bios, derrière le MBR, sur une partiton dédiée), mais la question mérite d'être posée.

  • # partitions étendues

    Posté par  . Évalué à 1.

    >une partition qui en contient deux autres, une partition utilisable et une nouvelle étendue(...)

    Oui-mais-bon on peut quand même faire 4 partitions primaires sous linux. Dos ne sait pas s'en dépatouiller, mais sur une machine exclusivement Linux, c'est pas un problème.

    • [^] # Re: partitions étendues

      Posté par  . Évalué à 1.

      Ah mais je crois que si. Si on crée 4 partitions primaires avec fdisk sous linux et qu'on les type et formate en FAT toute les partitions sont accessibles. C'est à vérifier cela dit, c'est un vieux souvenir du temps de mon DX/2

      • [^] # Re: partitions étendues

        Posté par  . Évalué à 5.

        La table de partition contient 4 entrées, donc il peut y avoir au maximum 4 partitions principales.
        Mais dès qu'on veut en ajouter une, il faut enlever une partition principale, crééer une partiton étendue (qui sera à la place de l'entrée de la table de partition qu'on vien de supprimer), mettre la partition ancienement principale dans cette étendue, et créer la nouvelle partition dans une partition étendue contenue dans la partition étendue qu'on vient de créer (euh... vous m'avez suivi ?).
        Ca donne (P=partition, E=partition étendue) :
        Avant :
        |--P1--|--P2--|--P3--|--P4--|

        Après :
        |--P1--|--P2--|--P3--|--E1--|
        
E1 = |--P4--|--E2--|
        
E2 = |--P5--|-vide-|

        (la partition étendue n'est pas forcément à la place de la 4ème partition)

        Mais il y a plus, car dans les partitions étendues, il y a une table de partition complète ! C'est à dire qu'idéalement, chaque partition étendue pourait contenir directement 4 partitions, ou 3+une étendue. Hors, une seule de ces entrées est utilisée, la seconde étant réservée pour une deuxième étendue.
        C'est tous ces petits champs inutilisés et sans documentation vraiment officielle qui a fait que je me suis lancé dans SPT.

        • [^] # Re: partitions étendues

          Posté par  . Évalué à 2.

          Je comprend bien, et STP est sûrement très souhaitable.
          Cela dit, pour le vulgus pecus comme moi, avec 4 partitions primaires sur un poste de travail, on est bien (et c'est simple).
          Maintenant, sur un serveur, il vaut peut-être mieux tailler sa hiérarchie à grands coups de machette ! :) Dans ce cas, STP est une très bonne nouvelle..

          • [^] # Re: partitions étendues

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

            Sur mon PC portable, le disque de 60Go a 7 partitions. Ce n'a rien d''exceptionnel. Cependant, le système qui est sur hda9 (la sixième partition) ne peut pas booter, ni lolo, ni grub n'arrivent à booter sur cette partition située à plus de 30Go du début.

            J'ai en fin de compte deux voeux : simplifier la numérotation des partitions et pouvoir lancer un système sur les derniers Go du disque sans avoir à recopier le noyau et initrd au début du disque.

            • [^] # Re: partitions étendues

              Posté par  . Évalué à 3.

              pouvoir lancer un système sur les derniers Go du disque sans avoir à recopier le noyau et initrd au début du disque.

              Pour ne plus avoir à se demander lorsque ca ne marche pas : est-ce pété ?

              ­La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham

  • # lilo?

    Posté par  . Évalué à 2.

    Il ne manque qu'un élément pour pourvoir s'affranchir du système actuel : un patch pour un lanceur (« bootloader ») afin de pouvoir démarrer un système d'exploitation sur un disque au format SPT.

    Il faudrait peut etre essayer avec lilo si ca n'a pas deja fait : en effet je crois qu'il file dirrectement les adresses des noyaux a booter : c'est pour cela qu'il faut le reinstaller a chaque fois...

    D'ailleurs pour le nouveau systeme de MS (ldm), ca ne marche qu'avec lilo.

    • [^] # Re: lilo?

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

      Exact, lilo connait l'emplacement physique du noyau sur le disque. Mais lilo, tout comme Grub, ne sait pas booter sur une partition située à plus de 30Go du début du disque.

      • [^] # Re: lilo?

        Posté par  . Évalué à 2.

        lilo et grub savent bouter des disques jusqu'à 2To, si le bios supporte le lba32.
        Soit pour des secteurs de 512 octets, 2^32*512 = 2To

        Le problème vient généralement du BIOS, ce qui est étrange pour un disque de 60Go dans un portable dont le BIOS ne devrait pas être trop poussiéreux. As tu vérifié le niveau de BIOS sur le site du constructeur ?

    • [^] # Re: lilo?

      Posté par  . Évalué à 3.

      Je viens d'essayer, mais ça ne marche pas. Voici la démarche pour debian, au cas où :
      -compiler un kernel avec spt.c et spt.h (plus quelques autres modifs pour intégrer le support, cf. site officiel)
      -installer ce kernel sur une debian en état de marche
      -redémarrer dessus
      -partitionner le disque (entre autres avec parted + une libparted compilée avec disk_spt.c et quelques modifs, cf. site officiel encore une fois)
      -formatter les partitons obtenues comme d'habitude
      -installer un système minimal avec debootstrap
      -installer le kernel compilé avec le support spt dans la debian obtenue avec debotstrap
      -installer lilo

      Mais au reboot, le MBR affiche le message "no active partition", car il doit tenter de lire tout de même la table de partitions. Je n'ai pas essayé de me battre plus avant, d'autant plus que j'ai fini de coder un ajout à grub2 et que j'attend seulement que la version cvs soit compilable pour le tester.

      Si quelqu'un arrive à obtenir quelque chose, je serais extremement heureux de pouvoir publier son MBR sur le site officiel.

      Au passage : le site est maintenant bilingue français/anglais, le forum a un flux rss, les sources du site sont disponibles (index.php, section download). Je recherche des personnes pouvant corriger les multiples fautes d'anglais que j'ai dû comettre dans la traduction (merci de poster les erreur trouvées et leur corrections dans la section prévue à cet effet dans le forum). Merci d'avance.

  • # Ouverture du forum

    Posté par  . Évalué à 5.

    Voila, comme prévu j'ai ouvert un forum sur le site officiel. Celui-ci devrait d'ailleurs faire l'objet d'un ravalement de façade durant le week-end.

  • # LVM

    Posté par  . Évalué à 3.

    Personnellement, je me demande plutôt pourquoi créer un noveau système de partitions.

    Pour ce qui est de mes installs perso (desktop), peu de partitions suffisent :
    dans le cas de hda :
    - /dev/hda1 swap
    - /dev/hda2 /
    - éventuellement une partition de data

    Pour ce qui est des serveurs (autant perso que pro), j'installe LVM, tout simplement. Je ne peux plus m'en passer :

    - /dev/hda1 swap
    - /dev/hda2 /
    - /dev/hda3 LVM
    Et ensuite, plein de partitions dans le LVM (/tmp, /usr, /var, /opt, /home, /var/log, /var/spool... ça dépend des besoins).

    Donc SPT (ou autre) n'a pas d'intéret pour moi, ma boîte, ou mes clients.

    J'ai récemment discuté avec des utilisateurs d'AIX (administrateurs d'espace disques), ils ont trouvé le système x86 aberrant. Eux, c'est un LVM pour la racine, et voilà, tout con tout simple. Un nommage totalement logique, aucune contrainte physique. Et ca, c'est top.

    • [^] # Re: LVM

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

      Si tu n'as pas besoin de plus de partitions, je veux bien le croire, mais ne généralise pas ton cas au monde entier.
      Quand on a plusieurs systèmes sur une même machine, le LVM n'est pas forcément la meileure solution.
      Par ailleurs, le système de partitionnement des disques des PC date de l'antiquité (de l'informatique).

      • [^] # Re: LVM

        Posté par  . Évalué à 2.

        Bien sûr, je ne parlais qu'en mon nom propre, et ne généralisais pas mon cas.


        Et justement, le reproche qu'on fait au partitionnement des PC, c'est qu'il date de l'antiquité... Les autres systèmes ont su évoluer.

        • [^] # Re: LVM

          Posté par  . Évalué à 4.

          "Les autres systèmes ont su évoluer."

          A la communauté du logiciel libre de proposer des nouveau systémes performant et efficace comme elle a pu le faire et le réussir dans le domaine des systémes de fichier.

          SPT est une premiére alternative axé sur quelques points précis, d'autre solution verront le jour avec d'autres objectifs. la multitude de choix du LL aura encore montré ca force !

          • [^] # Re: LVM

            Posté par  . Évalué à 6.

            Ben je partage l'analyse sur LVM.

            1/ LVM est AUTREMENT plus souple qu'un systeme de partitions.

            2/ changer de systeme de partitions c'est ecrire des drivers pour les autres OS.

            Je pense qu'a ce moment la, il vaut mieux ecrire des drivers LVM pour windows et les autres, comme ça tout lemonde peut utiliser le systeme le plus souple qui existe.

            le bémol c'est si on veut recuperer les datas avec un éditeur héxa comme lu plus haut, parce que en termes d'indirections LVM c'est balaize !

    • [^] # Re: LVM

      Posté par  . Évalué à 1.

      J'ai récemment discuté avec des utilisateurs d'AIX (administrateurs d'espace disques), ils ont trouvé le système x86 aberrant. Eux, c'est un LVM pour la racine, et voilà, tout con tout simple. Un nommage totalement logique, aucune contrainte physique. Et ca, c'est top.

      A la petite différence tout de même qu'AIX dispose de notions encore absentes du LVM de GNU/Linux à ma connaissance (mais j'avoue en connaitre assez peu de LVM)
      + D'une part, la gestion des volumes logiques d'AIX va de pair avec la notion de volume groupes (VG) qui permettent de s'abstraire des disques physiques
      + D'autre part, le LVM AIX me parait bien plus souple en termes de redimensionnement "à chaud" et de paramétrages (performances notamment).
      Idem sous True64.

      Pour finir, les disques que l'on trouve sur des machines faisant tourner AIX ou True64 n'ont rien de comparable avec ceux/celui de la machine perso' de monsieur-tout-le-monde... ne serait-ce qu'en termes de longevité.

      Pour ma part, je ne confirai pas à un LVM (ou à un RAID0 d'ailleurs) mon système perso', chose qui devient beaucoup plus envisageable sous de l'AIX/True64+LV/VG ...
      Sachant tout de même aussi qu'IBM ou ex-Compaq ont beau jeu d'offrir une solution simple dans la mesure où le matériel est imposé et que les versions d'OS ne prévoient aucune compatibilité ascendante. Changement de version majeure == changement de serveur...
      De mon côté, le GNU/Linux d'aujourd'hui tourne encore sur mon matériel d"hier :o)

      • [^] # Re: LVM

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

        + D'une part, la gestion des volumes logiques d'AIX va de pair avec la notion de volume groupes (VG) qui permettent de s'abstraire des disques physiques
        A désolé c'est le principe de base du LVM Linux (le linux est dans lvm mais je precise)

        + D'autre part, le LVM AIX me parait bien plus souple en termes de redimensionnement "à chaud" et de paramétrages (performances notamment).
        Idem sous True64.
        Tu peux détailler?
        Parce que bon le truc qui peut être "bloquant" c'est quand on utilise un FS qui va pas (le seul qui sois bien c'est reiserfs (aie le troll)):
        Tu peux augmenter ET reduire à chaud (pour réduire j'ai des doutes j'avoue)

        pourquoi pas un LVM chez toi?
        Moi je l'utilise bien, la seule raison c'est le redimensionnement à chaud (et repartitionnement à chaud avec)

        • [^] # Re: LVM

          Posté par  . Évalué à 2.

          Avec reiserfs, tu peux réduire le filesystem, mais pas à chaud. Par contre, pour agrandir, pas de problème.
          JFS et XFS, tu ne peux pas les réduire, mais tu peux les agrandir à chaud.
          ext2/ext3, pour les redimensionner à chaud, il faut un patch dans le kernel... ça me plait pas, à moi.

          • [^] # Re: LVM

            Posté par  . Évalué à 2.

            un patch dans le kernel ... ou une fedora core 3, livrée avec ext3fs redimentionable a chaud.

        • [^] # Re: LVM

          Posté par  . Évalué à 2.

          [...] c'est le principe de base du LVM Linux
          Cela signifie qu'à l'image d'AIX ou True64, LVM permet de faire de plusieurs disques physiques un disque logique (à l'image d'un RAID0 en plus souple) ?
          Si c'est le cas, il faut définitivement que je m'y intéresse (mais juste pour l'intérêt académique of course;o)

          Tu peux détailler ?
          Sous AIX, j'ai le souvenir de paramétrages permettant notamment de définir sur quels secteurs des disques le volume logique sera créé (en priorité selon le paramétrage d'autres VL), de redéfinir en cours de fonctionnement la taille des inodes, la taille du VL, d'ajouter/retirer des disques physiques d'un VG, etc...
          En outre, l'interface de SMIT (outil d'admin AIX) synthétise toutes ces manipulations et documente les commandes effectivement exécutées.
          Ces principes sont peu ou prou identiques sous True64 (si ce n'est au moins pour les possibilités de paramétrages) où les options du noyau concernant l'utilisation des disques sont très très étendues.

          En résumé, et je le répète, je connais mal le LVM GNU/Linux mais étant donnée la faible longévité des disques durs (toute relative mais je n'ai ni les moyens ni le temps de tout backuper + renouveler le matériel dès incident), je vois encore mal l'intérêt, pour mon usage, d'ajouter une couche logicielle supplémentaire dans la gestion des partitions juste pour avoir un regain de souplesse.
          Pour moi, les tailles et nombre de partitions sont plutôt figés (/, /boot, /usr, /usr/local, /var, /tmp, /home, éventuellement /var/log|apt). Dans le cas de besoins particuliers, il reste toujours possible de déplacer ce besoin sur d'autres partitions ou de recréer+recopier ailleurs.

          Je crois qu'il s'agit surtout d'habitudes mais actuellement je ne vois pas trop l'intérêt d'un LVM sous GNU/Linux si ce n'est un choix d'utilisation aucunement incontournable.
          Sur des *NIX proprio', cette souplesse est très appréciable car modification perso' rime souvent avec réinstallation ou perte du support (voire impossibilité en pratique) mais sous Linux le besoin me semble beaucoup moins criant.

          • [^] # Re: LVM

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

            Si c'est le cas, il faut définitivement que je m'y intéresse

            Oui c est le cas, et moi je migre à Noel. Sauf que sous la couche LVM, je vais mettre de l encryption AES128. L ordre est donc de bas en haut :
            - partitionnement
            - encryption
            - LVM
            - ReisorFS

            car Reisor est le seul a pouvoir etre reduit ou agrandi. Je suis fervent defensseur de XFS, mais il ne supporte pasd etre reduit sur du LVM. De meme, l encrypption ne peut pas etre redimentionnee, donc il faut le faire avant LVM. Avec de bonsscripts, tu peut avoir un mdp commun a tous les blocs LVM.


            Concernant le besoin de LVM, mon portable a 2 ans, j ai 5 OS dessus, et des fois j aimerais bien deplacer de l espace libre entre mes Linux. Tu peut voire ca autrement : je fais mes backups sur un dur externe en FAT32, qui ne peut contenire de fichier de plus de 2G: soit je dois couper ma sauvegarde en morceaux de 2G, soit je cre mirriade de fichiers de 2G, et les accole par LVM. La aussi un peu d AES permet de se proteger.

            • [^] # Re: LVM

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

              Sauf que sous la couche LVM, je vais mettre de l encryption AES128. L ordre est donc de bas en haut :
              - partitionnement
              - encryption
              - LVM


              T'aurais pas un ou deux liens pour commencer a voir comment ont fait ca s'il te plait?
              Parce que ca m'interesse de voir un peut comment ca marche. Si je comprend bien avec ca tes partitions sont cryptées, cela pose t'il un probleme en cas de rescue?

Suivre le flux des commentaires

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