De grootte van de mappen is onze moeite niet waard

Dit is een volkomen nutteloos, in de praktijk onnodig, maar grappig bericht over mappen in *nix-systemen. Het is vrijdag.

Tijdens interviews rijzen er vaak saaie vragen over inodes, alles-is-bestanden, die maar weinig mensen redelijk kunnen beantwoorden. Maar als je wat dieper graaft, kun je interessante dingen vinden.

Om het bericht te begrijpen, een paar punten:

• alles is een bestand. directory is ook een bestand
• de inode slaat metadata van het bestand op, maar de bestandsnaam wordt daar niet opgeslagen
• de bestandsnaam wordt opgeslagen in de directorygegevens
• De grootte van de map, dezelfde die wordt weergegeven in ls en standaard 4Kb is, hangt af van het aantal bestanden in de map en de lengte van hun namen
• Het is duidelijk dat hoe meer bestanden, hoe groter de mapgrootte

Nu komt het interessante deel: we maken een map met een miljoen bestanden, controleren de grootte van de map, verwijderen vervolgens alle bestanden en kijken naar de grootte van de map.

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

Zoals je kunt zien, is de mapgrootte niet veranderd, ook al lijkt het :)

Je kunt de grootte van een map alleen herstellen (zonder deze te verwijderen) met behulp van fsck (en de optie -D) in een niet-gemounte staat.

Maar toen ik ging zoeken waarom dit zo was, bleek dat dit gedrag 10 jaar geleden al bestond besproken in lkml. En volgens de ontwikkelaars is de oplossing simpelweg de moeite niet waard.

Bron: www.habr.com