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 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.
