[ext3] Hoeveel files maximaal in 1 directory?

[Snow_King]

Hoi,

Ik heb hier nu MRTG draaien ism GBGraph.

Op dit moment staan daar 1180 hosts in welke worden gemonitored, dat levert bij elkaar over de 11800 bestanden op in die directory.

Nu vroeg ik me af tot hoeveel bestanden ext3 maximaal in 1 directory aan kan.

Ik dacht 65536 (32bits), maar misschien ligt er een limiet bij ext3.

Wie kan dit voor mij ophelderen?

[junkbuster]

Ik zie in google newsgroepen berichten van iemand dat 'ie (in 2002) 2,7 miljoen files in een subdirectory (op een ext3 fs) had zitten en dat zonder problemen. Ik denk dat je dit zelf gewoon eens moet uitproberen. Draai een scriptje in elkaar dat een directory vult met (kleine) bestanden...

Ext3 wordt wel erg langzaam met zoveel bestanden, ik zou overwegen om naar een alternatief over te gaan. Reiserfs wellicht, die presteert waarschijnlijk veel beter.

edit: ik zocht op "ext3 how many files in directory" in http://groups.google.com/

[ Voor 10% gewijzigd door junkbuster op 04-08-2004 13:14 ]

[Wilke]

32 bits is sowieso geen 65536 (dat is 16 bits), maar 4 miljard en een beetje.

Er is bij mijn weten geen 'harde' limiet aan het aantal files in een directory in ext3 (maar ik heb het niet nagekeken). In ieder geval zal de grens zo groot zijn dat je er nooit tegenaan loopt.


Maar het wordt wel heel traag, omdat ext3 de bestanden in een directory in een gewone lijst (lineair dus) opslaat. Dus als je de laatste file in een directory wilt openen, loopt hij de hele lijst langs totdat hij uiteindelijk de laatste vindt. Dat wordt dus heel traag (zoektijd O(n) - dus per extra bestand wordt het een vaste hoeveelheid trager).

Een beter bestandssysteem om directories met achterlijk veel files op te zetten is ReiserFS. Deze bouwt een binary tree van de files in een directory, waardoor de zoektijd bij veel files veel kleiner is (namelijk O(2log(n)) - als de dir 2x zoveel files bevat wordt het een vaste hoeveelheid trager, da's dus veel beter).


Als dat je allemaal niks zegt, dan gewoon kort: ext3 - veel files per dir = traag, reiserfs: veel files per dir = geen enkel probleem.

12k files zit net een beetje op het randje van veel/niet veel. Je zou ook per host een directory kunnen maken, dan heb je 1180 directories met elk 10 bestanden. Da's sowieso voor geen enkel filesystem een probleem.

[Kees]

Snow_King schreef op 04 augustus 2004 @ 12:57:
Ik dacht 65536 (32bits), maar misschien ligt er een limiet bij ext3.

16 bits = 65535, 32 bits is (65536^2)-1
De limiet is voor zover ik weet gelijk aan het aantal inodes op je schijf, en hoeveel je daar van hebt wordt bepaald door het aantal blocks en de bytes-per-inode ratio. En dan maakt het geen bal uit in welke dir het staat.

[Snow_King]

Wilke schreef op 04 augustus 2004 @ 13:17:
32 bits is sowieso geen 65536 (dat is 16 bits), maar 4 miljard en een beetje.

Er is bij mijn weten geen 'harde' limiet aan het aantal files in een directory in ext3 (maar ik heb het niet nagekeken). In ieder geval zal de grens zo groot zijn dat je er nooit tegenaan loopt.


Maar het wordt wel heel traag, omdat ext3 de bestanden in een directory in een gewone lijst (lineair dus) opslaat. Dus als je de laatste file in een directory wilt openen, loopt hij de hele lijst langs totdat hij uiteindelijk de laatste vindt. Dat wordt dus heel traag (zoektijd O(n) - dus per extra bestand wordt het een vaste hoeveelheid trager).

Een beter bestandssysteem om directories met achterlijk veel files op te zetten is ReiserFS. Deze bouwt een binary tree van de files in een directory, waardoor de zoektijd bij veel files veel kleiner is (namelijk O(2log(n)) - als de dir 2x zoveel files bevat wordt het een vaste hoeveelheid trager, da's dus veel beter).


Als dat je allemaal niks zegt, dan gewoon kort: ext3 - veel files per dir = traag, reiserfs: veel files per dir = geen enkel probleem.

12k files zit net een beetje op het randje van veel/niet veel. Je zou ook per host een directory kunnen maken, dan heb je 1180 directories met elk 10 bestanden. Da's sowieso voor geen enkel filesystem een probleem.

ReiserFS ken ik wel ja.

Maar met MRTG geef je een workdir aan en je kan toch niet per host aan output dir aangeven?

[Paul]

Je kunt mrtg de logfiles, de images en de html ieder in een aparte dir laten zetten

Je moet dan wel even prutzen in gdbgraph omdat die standaard alleen de workdir directive aankan, maar als je die dan aanpast naar LogDir dan werkt het geloof ik weer

http://people.ee.ethz.ch/...tg-reference.html#htmldir
http://people.ee.ethz.ch/...g-reference.html#imagedir
http://people.ee.ethz.ch/...rtg-reference.html#logdir

Je hebt dan in iedere map nog maar 1/3 van de files. Tevens kun je de logfiles nu uit je webroot halen (geen idee wat er nu *exact* instaat en het dus nog een security-voordeeltje zou kunnen zijn, maar je bezoekers hoeven die bestanden toch niet te hebben )

[Kees]

Directory

By default, mrtg puts all the files that it generates for each target (the GIFs, the HTML page, the log file, etc.) in WorkDir.

If the Directory option is specified, the files are instead put into a directory under WorkDir or Log-, Image- and HtmlDir). (For example the Directory option below would cause all the files for a target ezwf to be put into directory /usr/tardis/pub/www/stats/mrtg/ezwf/ .)

The directory must already exist; mrtg will not create it.

Example:

WorkDir: /usr/tardis/pub/www/stats/mrtg
Directory[ezwf]: ezwf

Verder kun je ook aparte html en image dirs opgeven, zie de documentatie: http://people.ee.ethz.ch/.../mrtg/mrtg-reference.html

[Snow_King]

hmm ja, maar dan moet ik wel GBgraph gaan verbouwen.

Maar daar kan ik wel naar gaan kijken.

GBgraph2 gebruik ik overigens.