Taille réelle d'un fichier sur le disque

[Christian_B]

Bonjour,
J'ai voulu constituer un fichier texte plus ou moins aléatoire dont la recopie (puis la recopie d'un répertoire en contenant 100 exemplaire par exemple, etc) permettait facilement de remplir le disque dur pour effacer les secteurs vides (par principe plus que par nécessité).
Dans Xed, mon fichier comporte 98304 octets (soit 96 KiB).
Caja me donne bien 96 KiB pour la taille mais aussi 96 KiB pour la taille sur le disque. Or je m'attendais à 100 KiB avec un en-tête présumé de 4KiB.
Même la commande du donne 96 pour ce fichier et man du ne parle pas de l'en-tête.
Pour un répertoire de 100 fichiers identiques, la taille disque est 9,4 MiB pour Caja et 9604 pour du
Est-ce que je me trompe ou est-ce que pour connaître la place prise sur le disque il faut bien ajouter 4KiB par fichier ? A moins que Ext4 soit organisé autrement ?
Quelqu'un sait-il s'il existe un outil qui donne l'occupation réelle du disque par un fichier ou un répertoire ?
Merci.

[arghlub]

Salut,

• En terminal, pour connaître le poids d'un fichier :

  Code : Tout sélectionner

  du -h /chemin/vers/fichier

• Pour connaître le poids d'un dossier et de tous ses sous-répertoires (sur un seul niveau) :

  Code : Tout sélectionner

  du -hd1 /chemin/vers/dossier | sort -hr

Plus d'infos : viewtopic.php?p=157442#p157442

[cyrille]

https://unix.stackexchange.com/question ... than-4-kib

[arghlub]

ps :

Or je m'attendais à 100 KiB avec un en-tête présumé de 4KiB.

les 4kilos sont juste une en-tête, ce n'est pas le poids de ton répertoire/dossier

[arghlub]

pps :

Pour un répertoire de 100 fichiers identiques, la taille disque est 9,4 MiB pour Caja et 9604 pour du

Ça serait pas une histoire de conversion MiB → MB : https://www.gbmb.org/mib-to-mb ???

[Christian_B]

Ce qui me tracasse, ce n'est pas que du réponde sous la forme 96. j'avais compris qu'il s'agissait de K, (i.e. de Kio)
Le problème c'est que les en-têtes ne sont pas pris en compte alors qu'ils prennent de la place sur le disque. Ils ne font certes pas partie du contenu mais bien de l'occupation supplémentaire du disque si on ajoute un fichier.

J'avais toujours cru que la "Taille sur le disque" dans Caja représentait "l'encombrement réel". C'est trompeur. Évidemment, le sachant je peux faire le calcul (selon le nombre de fichiers pour un répertoire).
C'est encore en plus flagrant sur un répertoire de 100 fichiers de 96 kiB du trouve 9604 (KiB, je n'utilise pas -h qui convertit MiB et complique le calcul).
Car du travaille bien en KiB ou MiB quoiqu'il les nomme K et M.
Mon fichier fait 98304 octets, i.e. 98,3 MB ou 96 MiB. Le calcul de du est donc juste (en KiB) si on ne tient pas compte des en-têtes.
Je m'avise qu'une partie de ma surprise venait du chiffre de 9,4 MiB de Caja. En fait en KiB soit 9,4 × 1024 ≃ 9626 Kio, pareil que du à l'arrondi près. Je n'y avais pas réalisé tout se suite.

Par ailleurs les explications du lien stackexchange de cyrille me surprennent. Si on ne compte pas la taille des en-têtes, pourquoi prendrait-on en compte les blocs "indirects" qui ne font pas non plus parti du contenu ?
J'ai fait un répertoire de 100 répertoires de 100 fichiers et du me donne 960404 comme résultat pour ce répertoire. En fait un bloc supplémentaire par répertoire. Sans doute uniquement un bloc (en plus de son en-tête) utilisé pour la liste des fichiers (i.e.de leurs inodes je suppose). Cela ne me paraît pas très cohérent. La commande filefrag que ce soit pour le fichier, pour un gros ou un petit répertoire parmi les précédents, répond toujours : 1 extent found.
Je suppose qu'il faut "faire avec" et ajouter 4KiB × Nombre_de_fichiers.

[philosophedesetoiles]

Slt,

La gestion disque par ext4 est complexe.
entetes, inodes, pointeurs etc...
sans compter les algorithmes d'allocation et d'optimisation.
Les tailles des secteurs physiques ne sont pas strictu sensus identiques aux tailles logiques.

Un peu de doc : ( courage ! )

https://www.it-swarm-eu.dev/fr/hard-dis ... 960881947/

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

[Christian_B]

Merci philosophedesetoiles.

En fait la 1ère référence (sur it-swam-eu.dev) n'est pas claire sur la différence entre secteur physique et secteur logique. J'ai trouvé des explications bien plus claires et complètes par exemple sur :
https://www.malekal.com/secteur-cluster ... -que-cest/
D'autre part il y a des erreurs bizarres dans la dernière réponse "512 Ko" et "4 096 Ko (4 Mo)" pour 512 et 4096 octeets.
Par contre ses commandes me redonnent (je l'avais oublié) :
secteur physique = 4096 octets (sur ma SSD système et mon disque principal)
secteur logique = 512 octets (idem).

La 2e référence (sur ext4.wiki.kernel.org) est beaucoup plus pointue, je n'ai pas tout regardé en détail.
Je me demandais quelle était la relation entre secteurs (physiques ou logiques) dans mon cas.
J'ai fait un fichier de 95 Kio (97280 octets). Il occupe exactement la même place (96 Kio) que mon fichier de 96 Kio.
Donc les blocs d'allocation se font bien par 4 Kio. Si je comprends bien on découpe les blocs physique en 8 .. pour rassembler ensuite les 8 morceaux en un bloc. Très efficace !

D'après ces explications il est difficile de connaître exactement l'encombrement disque supplémentaire résultant de la création d'un fichier. Et impossible de le savoir à priori.
Mais il n'y avait rien sur les "en-têtes de fichiers" (nom, dates, etc) dont je m'inquiétais.
J'ai fini par comprendre qu'il n'y avait pas une "en-tête" mais d'une part les dates et autres métadonnées techniques dans l'inode (de 256 octets si j'ai bien compris) et d'autre part le "nom du fichier", associé au lien physique défini dans le répertoire et non au fichier.
Donc j'étais parti sur une idée fausse. Je me baserai sur l'idée que le fichier prend "un peu plus" que la taille annoncée.
Donc le problème est [autant que possible] résolu.

[alain]

Bonjour.

Sujet archivé (en lecture seule) car résolu.
Si besoin de rouvrir faire un MP à un membre de l'équipe