Forum général.général Système de fichier minimal

Posté par  (site web personnel) .
Étiquettes :
3
20
fév.
2012

Bonjour,

Je me pose depuis un moment une question, purement théorique (je n'ai pas en tête d'application pratique directe, ou alors quelques bribes) :
Quel serait le système de fichier le plus adapté pour des partitions (ou fichiers blocs) toutes petites (quelques Mo voir plus petit) ? L'idée serait que le système de fichiers ne prenne que le moins de place possible, que le résultat obtenu tendrait vers un 'df' à vide de la partition à peu près équivalente à la taille effective du bloc.
Il y avait bien fat16 à l'époque, mais bon, j'aimerais bien un système de fichier plus moderne (notamment supportant l'unicode, ce serait bien…), et surtout libre…

Edit :
J'ai testé avec des fichiers de 1Mo en loop, et ça donne ça (avec la commande df -h) :
/dev/loop0 2,0M 0 2,0M 0% /dev/shm/tests/_0
/dev/loop1 2,0M 21K 1,9M 2% /dev/shm/tests/_1
/dev/loop2 2,0M 1,1M 859K 56% /dev/shm/tests/_2
/dev/loop3 2,0M 1,1M 864K 55% /dev/shm/tests/_3
Avec respectivement loop0, loop1, loop2 et loop3 en fat32, ext2, ext3 et ext4.

  • # Commentaire supprimé

    Posté par  . Évalué à 4.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Il y a beaucoup de param qui rentrent en jeux

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 21 février 2012 à 06:28.

      On peut aussi (ou en plus...) déporter le journal ailleurs, dans le cas des FS EXT au moins. Qu'en penses tu ? Par exemple :

      mkfs.ext3 -O journal_dev /dev/loop2 && mkfs.ext3 -J device=/dev/loop2 /dev/loop1

      Pour le coup, son fs sur loop1 sera disponible "au maximum". Je sais que cela ne réponds pas complètement à sa question, mais il s'agit simplement d'une autre possibilité pour obtenir son objectif : un device totalement 'libéré' (ici de l'espace occupé par le journal, mais sans perdre les fonctionnalités du journal ...)

      • [^] # Re: Il y a beaucoup de param qui rentrent en jeux

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

        Ah oui, une piste très intéressante. C'est vrai que je n'avais jamais pensé pouvoir séparer le journal de la partition…
        Ça m'apprendra à survoler les pages de man !

        Merci pour tes (vos) réponse(s).

        La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

  • # ls /usr/src/linux/fs/

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

    • [^] # Re: ls /usr/src/linux/fs/

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

      Très intéressant tout ça…
      Je retiendrais notamment la possibilité de compresser un système de fichier squashfs, ce qui est bigrement utile dans le cas de touts petits blocs.

      Par contre, la limite évidente de ces systèmes de fichier, c'est le fait qu'ils soient en read-only…

      Mais bon, ça pourrait coller à une application à laquelle j'avais pensé, qui serait de faire une mini-partition cachée dans une clé usb ou une carte SD, qui contiendrait les clés de chiffrement des partitions d'un ordinateur portable par exemple. Ça ferait de a clé usb une sorte de "clé de contact" de l'ordinateur, sans laquelle il ne pourrait pas booter.

      Merci pour ta réponse que je vais creuser de ce pas.

      La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.

  • # pour EXTx, en limitant les allocations reservées

    Posté par  . Évalué à 1.

    par defaut pour les systemes de fichiers EXTx il y a un certain pourcentage (10% je crois) qui est reservé à root.

    tune2fs -m 0 /dev/sdX

    te permet de reduire ce pourcentage à 0% et donc de recuperer un peu de place (tres visible sur les gros disques)

Suivre le flux des commentaires

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