Gidsgrootte is nie ons moeite werd nie

Hierdie is 'n heeltemal nuttelose, onnodige in praktiese toepassing, maar snaakse klein plasing oor dopgehou in *nix-stelsels. Dit is Vrydag.

Tydens onderhoude ontstaan ​​dikwels vervelige vrae oor inodes, alles-is-lêers, wat min mense met verstand kan beantwoord. Maar as jy 'n bietjie dieper delf, kan jy interessante dinge vind.

Om die pos te verstaan, 'n paar punte:

• alles is 'n lêer. gids is ook 'n lêer
• die inode stoor metadata van die lêer, maar die lêernaam word nie daar gestoor nie
• die lêernaam word in die gidsdata gestoor
• Die grootte van die gids, dieselfde een wat in ls gewys word en by verstek 4Kb is, hang af van die aantal lêers in die gids en die lengte van hul name
• Natuurlik, hoe meer lêers, hoe groter is die gidsgrootte

Nou hier is die interessante deel: ons skep 'n gids met 'n miljoen lêers, kontroleer die grootte van die gids, en vee dan al die lêers uit en kyk na die grootte van die gids.

$ mkdir niceDir && cd niceDir
# в зависимости от скорости носителя, следующая команда может занять 2-10 минут
$ for ((i=1;i<133700;i++)); do touch long_long_looong_man_sakeru_$i ; done
$ ls -lhd .
drwxr-xr-x 2 user user 8.1M Aug 2 13:37 .
$ find . -type f -delete
$ ls -l
total 0
$ ls -lhd .
drwxr-xr-x 2 user user 8.1M Aug  2 13:37 .

Soos u kan sien, het die gidsgrootte nie verander nie, alhoewel dit lyk :)

U kan slegs die grootte van 'n gids regmaak (sonder om dit uit te vee) met behulp van fsck (en die -D-opsie) in 'n ongemonteerde toestand.

Maar toe ek gaan soek het hoekom dit so was, het dit geblyk dat 10 jaar gelede al sulke gedrag het bespreek in lkml. En volgens die ontwikkelaars is die oplossing eenvoudig nie die moeite werd nie.

Bron: will.com