Size directory met heel veel files

[Yarisken]

Hallo,

We hebben hier een directory op een linux bak met 250.000 folders en 2,7 miljoen files ongeveer.
Als ik de size wil weten dan doe ik du -sh. Dit kan heel lang duren voor ik hier output van krijg.
Als ik zoek naar een andere oplossing kom ik eigenlijk altijd bij "du" uit.
Zijn er mensen die een snellere oplossing weten om de size te kennen van zo'n grote directory ?

[Hero of Time]

Niet echt. Tools als 'du' vragen van elk bestand de grootte op en telt dat uiteindelijk bij elkaar op om tot het totaal uit te komen. Ook via een file manager wordt er van elk bestand opgevraagd hoe groot deze is. Je ontkomt er dus niet aan.

[Yarisken]

Hero of Time schreef op dinsdag 15 september 2015 @ 13:06:
Niet echt. Tools als 'du' vragen van elk bestand de grootte op en telt dat uiteindelijk bij elkaar op om tot het totaal uit te komen. Ook via een file manager wordt er van elk bestand opgevraagd hoe groot deze is. Je ontkomt er dus niet aan.

Idd, ik vreesde er ook voor. Thx voor de reply.

[Hero of Time]

En anders dump je die zooi op een eigen schijf/partitie en doe je via 'df -h' het gebruik uitlezen.

[Yarisken]

Hero of Time schreef op dinsdag 15 september 2015 @ 13:09:
En anders dump je die zooi op een eigen schijf/partitie en doe je via 'df -h' het gebruik uitlezen.

Inderdaad, binnen 2 maand hebben we hier nieuwe storage en dan maken we een mount via nfs en dumpen we daar heel die directory op. Da's makkelijker voor backup en om uit te lezen.

[d1ng]

Tot die tijd kun je een exclude doen met du.

code:

du -sh filesystem --exclude ongelooflijkgrotemap

En dan het verschil uitrekenen met de uitkomst van je df

[ Voor 31% gewijzigd door d1ng op 15-09-2015 18:48 ]

[Yarisken]

d1ng schreef op dinsdag 15 september 2015 @ 18:47:
Tot die tijd kun je een exclude doen met du.

code:

du -sh filesystem --exclude ongelooflijkgrotemap

En dan het verschil uitrekenen met de uitkomst van je df

Lol idd dat is ook een mogelijkheid :-)

[Wolfboy]

Het hangt natuurlijk geheel van je write load af, aangezien du van elk bestand de grootte gaat uitlezen kan dit best traag zijn dus als de mappen op een of andere manier zo ingedeeld zijn dat je kan zien welke wel/niet geupdate zijn dan kan je natuurlijk gewoon delen updaten.

du (*~oude_map~andere_oude_map)

[init6]

Gebruik find?

[Cyphax]

Yarisken schreef op dinsdag 15 september 2015 @ 13:01:
Hallo,

We hebben hier een directory op een linux bak met 250.000 folders en 2,7 miljoen files ongeveer.
Als ik de size wil weten dan doe ik du -sh. Dit kan heel lang duren voor ik hier output van krijg.
Als ik zoek naar een andere oplossing kom ik eigenlijk altijd bij "du" uit.
Zijn er mensen die een snellere oplossing weten om de size te kennen van zo'n grote directory ?

Of het sneller is qua filesizes uitrekenen weet ik niet (zal wel niet) maar misschien is ncdu een goeie om te proberen. Da's een ncurses-variant op du, die maakt het navigeren door directories wat makkelijker dus misschien werkt dat in de praktijk wat fijner. En je hoeft ook maar 1 keer te laten scannen.

http://dev.yorhel.nl/ncdu

[deadinspace]

init6 schreef op woensdag 16 september 2015 @ 11:23:
Gebruik find?

Wat zou de TS met find moeten doen, en waarom zou dat helpen?

[init6]

deadinspace schreef op woensdag 16 september 2015 @ 16:39:
[...]

Wat zou de TS met find moeten doen, en waarom zou dat helpen?

Bash:

find /var -printf %k"\n" | awk '{  sum += $1 } END { print sum }'

Omdat het sneller kan zijn.

[ Voor 6% gewijzigd door init6 op 17-09-2015 10:22 ]

[deadinspace]

init6 schreef op donderdag 17 september 2015 @ 10:21:
Omdat het sneller kan zijn.

Daar geloof ik helemaal niks van

Zowel du als find moeten recursief alle files inspecteren om de grootte op te vragen. Dat leidt tot veel scattered reads, wat het zo traag maakt. Ik vermoed dat die twee manieren onder dezelfde omstandigheden precies even snel gaan zijn.

(Het enige verschil dat ik kan bedenken is dat de een misschien BFS doet, en de ander DFS, maar ik betwijfel of dat veel uit gaat maken. Bovendien vermoed ik dat beiden DFS doen, aangezien dat net iets makkelijker is)

[begintmeta]

wil je trouwens filesizes weten of bezette blocks? Voor het eerste doe je nu sowieso niet het goede

Je zou eventueel ook kunnen kijken of je met quota iets zou kunnen construeren, en als je bijvoorbeeld btrfs zou gebruiken is een subvolume ook snel gemaakt.

Misschien sowieso wel interessant het fs te weten, verschillende fss maken wellicht verschillende oplossingen mogelijk. Ik weet ook niet wat vooor bestanden het zijn en hoe ze gebruikt worden, maar misschien is een andere structuur dan een standaard fs (bijvoorbeeld een database, of tablefs-achtig) ook wel geschikt ervoor.

[ Voor 55% gewijzigd door begintmeta op 17-09-2015 14:40 ]

[Kees]

De snelste oplossing die ik ken is ze in een aparte partitie zetten, (bijvoorbeeld op een systeem met btrfs). Dan kun je gewoon df gebruiken.

[begintmeta]

Kees schreef op donderdag 17 september 2015 @ 19:03:
De snelste oplossing die ik ken is ze in een aparte partitie zetten, (bijvoorbeeld op een systeem met btrfs). Dan kun je gewoon df gebruiken.

Alleen is dat eigenlijk geen oplossing voor de exacte som van filesizes natuurlijk. Maar zoals inmiddels meerderen hebben aangegeven lijkt een partitie (of btrfs subvolume) wel een goed idee, waarschijnlijk ook wel wat de ts wil.

Eventueel kan het ook schelen zelf een binary te maken die eventueel wat lager niveau calls gebruikt (bijvoorbeeld fstatat64). Vziw houden de gangbare filesystems geen metadata over de grootte (in blocks of bits) van bestanden in een directory bij, alleen de bestandsgrootte zelf. Dan kom je dus uit op het optellen van alle filesizes, en dat kost tijd. Door juist opgezette quota te gebruiken zou je die benodigde tijd eerder kunnen investeren (maar ook alleen voor blocks). Andere structuren (of filesystems die ik niet ken) zouden eventueel wel de juiste metadata bijhouden. Of je maakt zelf iets wat die gegevens bijhoudt (eventueel ook met gebruik van fsnotify) en naar bijvoorbeeld xattrs schrijft.

[ Voor 10% gewijzigd door begintmeta op 17-09-2015 19:50 ]

[deadinspace]

begintmeta schreef op donderdag 17 september 2015 @ 19:43:
Eventueel kan het ook schelen zelf een binary te maken die eventueel wat lager niveau calls gebruikt (bijvoorbeeld fstatat64).

Ik denk niet dat dat veel gaat helpen; je hebt nog steeds een (f)stat(at) - en dus sytem call - per file nodig, en je moet nog steeds enorm veel inodes van disk halen in een volgorde die waarschijnlijk alles behalve lineair is. Je bespaart er wellicht wat berekeningen mee, maar dat is niet waar de tijd in zal zitten.

Door juist opgezette quota te gebruiken zou je die benodigde tijd eerder kunnen investeren (maar ook alleen voor blocks).

Dat is wel een slim idee! Als je dat goed doet heb je de voordelen van het aparte filesystem zonder dat je daadwerkelijk een apart fs moet gaan maken en de data kopieren

[begintmeta]

deadinspace schreef op donderdag 17 september 2015 @ 20:58:
...
Ik denk niet dat dat veel gaat helpen; ... maar dat is niet waar de tijd in zal zitten.

Dat denk ik ook niet. Je zou zoiets nog wel in een eigen daemontje die fileacces bewaakt en periodiek de filesizes dan update (in een file of xattrs) kunnen gebruiken. Kan wel nogal wat overhead geven natuurlijk als er snel duizenden files zouden bijkomen etc.

Dat is wel een slim idee! Als je dat goed doet heb je de voordelen van het aparte filesystem zonder dat je daadwerkelijk een apart fs moet gaan maken en de data kopieren

Ook daarmee zal je natuurlijk niet de filesize, maar zoals aangegeven de blocks vinden. btrfs subvolumes zouden op zich in dit geval ook wel handig zijn.

Als de TS wat meer informatie zou geven over hoe (en hoe snel) de files ontstaan, of ze later van grootte kunnen veranderen (of kunnen verdwijnen), welk filesystem nu wordt gebruikt etc zou men denk ik wel beter kunnen nadenken over het probleem

[ Voor 3% gewijzigd door begintmeta op 17-09-2015 21:11 ]

[Cyphax]

Kees schreef op donderdag 17 september 2015 @ 19:03:
De snelste oplossing die ik ken is ze in een aparte partitie zetten, (bijvoorbeeld op een systeem met btrfs). Dan kun je gewoon df gebruiken.

Hoe zou je dat doen? Zonder ze te verplaatsen?

[Hero of Time]

Cyphax schreef op donderdag 17 september 2015 @ 21:34:
[...]

Hoe zou je dat doen? Zonder ze te verplaatsen?

Door de rest van de schijf te gooien.