Informatique Linux Kernel/File system/HDD

dilondilon2

Cyberdépendant avéré
19 Avril 2012
1 021
327
88
DTC
Je pose ce topic ici, on sait jamais, si ça peut intéresser quelqu'un et sachant qu'il y a quand même bon nombres de personnes plutôt douées à priori en ce lieu. ( et n'ayant pas envie d'aller m'inscrire autre part pour le moment )

Je vais essayer de faire court et pas trop bordélique pour poser ma/mes questions, mais je ne promet rien...

Si l'on part du principe, pour le stockage sur disque dur (block device) dans un système de fichier en ext2, de l'allocation par block, on vois que pour chaque nouvelle écriture de fichier, le kernel alloue une nouvelle inode, qui contient elle même une série de pointeur sur des block de données. Block qui sont généralement alignés sur la taille des pages du système d'exploitation. ( on va prendre l'exemple de pages de 4096 octets ).

On peut en conclure: chaque nouveau fichier prend en réalité un minima de 4ko d'espace alloué ( 1 block ), peux importe la taille du dit fichier, et ce, bien que l'os lui, nous rapporte une taille de fichier de x octets. Dans un fichier contenant 3 caractères à titre d'exemple, l'analyse de sa taille nous indiquerait que 4 octets ont été copiés sur le disque. ( en comptant le null-byte final )

J'en suis arrivé à une conclusion qui me paraît relativement bizarre.
On prend un exemple sur un disque de 500Go. ( donc 500 000 000 000 octets )
Si on copie maintenant sur ce même disque, une série de 122 070 312 fichiers de 1 octet chacun. ( qui alloueront donc ce même nombre de block/pages sur le hdd ), on occuperait désormais les 500Go du disque dur alors que le système d'exploitation nous indiquerait quant à lui que nous occupons uniquement 122 070 312 octets ( soit 122 Mo, wtf ).
Est ce bien la réalité ou est ce que j'oublie un gros détails dans l'histoire?*

Après on peux imaginer que le système d'exploitation prend en compte ce détails dans l'affichage de la place restante sur le disque dur. ( ce que je n'ai pas pu constater en tout cas )
Mais bref passons.

Le simple fait que 122 070 312 fichiers de 1 octets puissent occupé l’entièreté d'un disque dur de 500Go me parait très très étrange.

J'ai donc réfléchi à comment pouvait se passer les choses autrement, mais je ne vois malheureusement pas.
Je suis parti notamment sur l'idée qu'un secteur de disque fait dans la plupart des cas 512 octets et donc, qu'au delà de l'allocation virtuel, un mécanisme sous-jacent du kernel ne complétait pas les blocks de disque entièrement mais seulement sur le nombre de secteurs occupés réellement.
Si c'était le cas, est ce que l'un d'entre vous aurait des renseignements sur ce mécanisme ou pourrait m'orienter sur de la documentation adéquate. ( je ne vois pas comment le kernel pourrait s'y pendre et je ne pense pas que cela soit le cas )

Après je n'ai pas trouvé mieux et je vois encore moins comment une autre technique pourrait être implémentée.

Donc, est il réellement possible d'utiliser la taille maximum un disque dur en utilisant uniquement 0,024% de sa taille réel? ^^


*les calculs sont très approximatifs ( base 10, élément volontairement mit de coté tel que boot-block, tailles des inodes et de leur table.. etc etc )


EDIT: sinon je pensais également un un mécanisme de type "budy/slab allocation" comme ce qu'il se fait pour la gestion de la mémoire. Mais je ne trouve pas de renseignements la dessus.
 
Je ne saurais t'aider d'avantage, mais d'après ce que j'ai lu, un tel disque ne pourrait contenir qu'un peu plus de 61 000 000 fichiers et dossiers, soit la moitié (octets/2^13).
Mais ça ne devrait rien changer au problème si les fichiers étaient de 2 octets.

Je crois que la vraie question est : Qu'est ce qu'on ferait avec plusieurs dizaines de millions de fichiers aussi petits ? :)
 
  • J'aime
Reactions: dilondilon2
Je crois que la vraie question est : Qu'est ce qu'on ferait avec plusieurs dizaines de millions de fichiers aussi petits ? :)

Ouais j'en arrive aussi à cette conclusion pour le moment: les concepteurs n'ont certainement pas prévu qu'un utilisateur soit aussi con..

Par contre, d’où sort tu cette information sur la limite de quantités de fichiers d'un disque?
Enfin théoriquement c'est le nombre d'inodes maximal que peux contenir la partition (déterminé je ne sais trop comment, encore une autre bonne question^^ ) qui détermine le nombre de fichiers pouvant être créés.
Après c'est qu'une valeur théorique, et du coup, peu réaliste. Mais c'est apparemment assez vague de savoir combien de fichiers et dossiers peux réellement contenir au maximum un hdd.

Par contre, si on prend en compte la quantité max de création de fichiers <= une page, et qu'on prend effectivement un système d'exploitation avec une taille de page de 8192 octets, on arrive effectivement à se résultat.
Pour ça, si tu as la source de cette info, ça pourrait grandement m'aider en fait. Ca voudrais dire que je ne suis pas complètement à coté de la plaque.
 
Bien vue et merci. Il faudrait désormais que je trouve pourquoi ils font cela comme calcul.
Ils prennent peu être une marge puisque le disque dur ne contient pas uniquement des datas-block. Et puisque, comme tu le disais, concrètement on s'en fou de créer des fichiers de seulement quelques octets, diviser ça par deux n'a aucun impact.