konyvtar merete (sok file van alatta) hogyan?

UNIX haladó

Adott egy konyvtar (/mnt/a), ami alatt 00..ff/00..ff/00..ff/ konyvtarszerkezet van, es a 3. szint alatt van egy zsak file (szetszorva ebben a strukturaban). Hogyan szamolnad ki/meg az /mnt/a alatti file-ok meretet? (Blokkmeret is jo, sot, az talan meg jobb is).

Egy huszarvagasom lenne a feladatra, de az elejen meg nem akarom ezzel befolyasolni a fogekony olvasokat.

  • 6205 megtekintés

( lx | 2012. 02. 10., p – 11:23 )

Mármint a
du -s /mnt/a
parancs helyett keresel egy alternatívát?

Ha fontos a sebesség, akkor lehet mind külön-külön mountpoint, és df

Ez nem jarhato ut, mert

- a konyvtarak on-the fly jonnek letre, amikor fajl kerul belejuk
- a menedzselesuk kaosz lenne

Az en titkos favoritom a /mnt/a-t kulon particiora tenni, es arra df, de ez is max. a 2. legjobb megoldas lehet, mert a szinten a gepen levo sql-be is azert kerulnek rendesen adatok, igy ket particiot kell 1 helyett ugyesen beloni/monitorozni/lvextend-elni/whatever.

Ezert en egy olyan megoldast preferalnek, amihez nem kell 2 (vagy tobb) particio, es elfogadhato diszk tekeres (=io terheles) mellett elfogadhato ido alatt kikopi az eredmenyt.

Palgium

A file krealas frekvenciajatol fuggoen akar - ha lehetseges a kod beepitese - akar nyilvan is lehet tartani valami zarolhato helyen az adathalmaz meretenek valtozasat es akkor nem kell disk io-ra sem varni. Esetleg az fs event loggerre rakotni egy apro appot ami ugyanezt muveli close()/rm() eseten. Olcso buli mind a ketto.

---
pontscho / fresh!mindworkz

Linux alatt soha nem kvótáztam, ezért meglehet, hogy sántít a dolog (fixme, pls):
- a kérdéses könyvtár alá nem partíciót, hanem jó nagy diszk imidzset tenni,
- arra fájlrendszer, arra kvóta, amely "jó nagy" (megegyezik az img méretével),
- a kvóta helyzetét lekérdezni.

Az img persze nem gyorsít semmit, csak kiküszöböli további partíció bevezetését, de a kvóta folyamatosan karbantartott dolog.

bonyolult, es en a Murphy 'ami el tud romlani, az el is fog' szellemeben a leheto legegyszerubben szeretnem megoldani a taszkot.

Arrol nem is beszelve, hogy ha pl. (ok, ez mondjuk kiepites fuggo) kesobb, menet kozben a gepbe tolsz meg par db diszket, akkor nem trivialis boviteni az image-et, novelni a kvotat, stb. De ertekelem az otletet :-)

Palgium

szeretjuk az xfs-t, viszont az alabbiakat kiadva a vegen egy kis problema adodik:

#mount -o pquota,prjquota,pqnoenforce,remount /
#echo 42:/var/log >> /etc/projects
#echo logfiles:42 >> /etc/projid
#xfs_quota -x -c 'project -s logfiles' /
Setting up project logfiles (path /var/log)...
Processed 1 (/etc/projects and cmdline) paths for project logfiles with recursion depth infinite (-1).
#xfs_quota -x -c 'limit -p bhard=1g logfiles' /
xfs_quota: cannot set limits: Function not implemented
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Palgium

A te igényedhez (csak accounting, ezért is a pqnoenforce) nem is kell konkrét kvótát beállítani, anélkül is megy a report.

Mindemellett működik a hardlimit beállítása a fenti módon, de úgy tűnik, az első projektkvóta beállítása előtt mount kell, és nem elég a remount. Egy umount, majd mount után rendben van. (A root FS esetén kicsit nehéz ezt élő rendszer alatt megoldani, de azt is el tudom képzelni, hogy elég RO-ra, majd RW-re remount.).

Alaphelyzet:

/etc/fstab: 

/dev/mapper/vg0-usr_local_src /usr/local/src  xfs       defaults        0       2

root@a:~# mount | grep /usr/local/src
/dev/mapper/vg0-usr_local_src on /usr/local/src type xfs (rw)
root@a:~#

/etc/fstab: 

/dev/mapper/vg0-usr_local_src /usr/local/src  xfs       defaults,pqnoenforce        0       2

root@a:~# mount -o remount /usr/local/src
root@a:~# mount | grep /usr/local/src
/dev/mapper/vg0-usr_local_src on /usr/local/src type xfs (rw,pqnoenforce)
root@a:~# grep /usr/local/src /proc/mounts
/dev/mapper/vg0-usr_local_src /usr/local/src xfs rw,relatime,attr2,noquota 0 0
root@a:~#


root@a:~# mkdir /usr/local/src/valami
root@a:~#


root@a:~# xfs_quota -x -c 'project -s valami' /usr/local/src
Setting up project valami (path /usr/local/src/valami)...
Processed 1 (/etc/projects and cmdline) paths for project valami with recursion depth infinite (-1).
root@a:~#

Ahogy írtad, hiba jön, az oka látszott az előbb a /proc/mounts-ban: 

root@a:~# xfs_quota -x -c 'limit -p bhard=1g valami' /usr/local/src
xfs_quota: cannot set limits: Function not implemented
root@a:~# xfs_quota -xc 'report -h' /usr/local/src
root@a:~#

 
 
 

De a pqnoenforce-szal mountolva jó: 


root@a:~# umount /usr/local/src
root@a:~# mount /usr/local/src
root@a:~# mount | grep /usr/local/src
/dev/mapper/vg0-usr_local_src on /usr/local/src type xfs (rw,pqnoenforce)
root@a:~# grep /usr/local/src /proc/mounts
/dev/mapper/vg0-usr_local_src /usr/local/src xfs rw,relatime,attr2,pqnoenforce 0 0
root@a:~#

root@a:~# echo alma >/usr/local/src/valami/almafa
root@a:~# xfs_quota -xc 'report -p' /usr/local/src
Project quota on /usr/local/src (/dev/mapper/vg0-usr_local_src)
                               Blocks
Project ID       Used       Soft       Hard    Warn/Grace
---------- --------------------------------------------------
valami              4          0          0     00 [--------]

root@a:~#


root@a:~# xfs_quota -x -c 'limit -p bhard=1g valami' /usr/local/src
root@a:~# xfs_quota -xc 'report -p' /usr/local/src
Project quota on /usr/local/src (/dev/mapper/vg0-usr_local_src)
                               Blocks
Project ID       Used       Soft       Hard    Warn/Grace
---------- --------------------------------------------------
valami              4          0    1048576     00 [--------]

root@a:~#

A rendszer aktuális Debian Squeeze 6.0.4, 2.6.32-5-amd64 kernel, xfsprogs 3.1.4.

Már egyszer átnéztem emiatt a mant, de átsiklottam felette. Ez a válasz a root FS-re:

man xfs_quota:
QUOTA ADMINISTRATION
  4. Turning on quotas on the root filesystem is slightly different from the above. For IRIX XFS, refer to quotaon(1M). For Linux XFS, the quota mount flags must be passed in with the "rootflags=" boot parameter.

( oszkar v | 2012. 02. 10., p – 11:43 )

Gnome Commander-ben space a könyvtár nevén.

( zx81 v | 2012. 02. 10., p – 12:02 )

Lehet rosszul gondolom, de a du -s /mnt/a/* nem lenne egyszerűbb?

---
debian squeeze

Mondjuk az SQL-es megoldas jo, de mi van ha taintelik?

az problema, bar nem show stopper: a tarolt levelek meretet mutatna meg, azaz hogy pl. 300 GB van az archivumban

ha az osszes fajlnevrol van katalogusod, akkor akar parhuzamosan is lefuttathatod egyesevel rajuk - kiadsz sok-sok kis du-t majd te magad osszegzel. FS fuggvenyeben az I/O nem biztos hogy szeretni fog erte persze.

potencialisan tobb millio file-rol lehet szo (akar) 256^3 konyvtarban. Ennyi du-t nem tudok lefuttatni. Meg az xfs projekt kvota tunik hasznalhatonak, csak epp nem jon ossze nalam :-)

Palgium

nem egeszen ez a feladat. Egy email archivalo projektrol van szo, ami megmutatja, hogy osszesen hany GB-nyi level van az archivumban. Ennek nem kell grammra pontosnak lennie, mert az tkp. tokmindegy, hogy 300.000000 (of 1000.00) GB vagy 300.4 (of 1000.00) GB van benne, ez inkabb egy tajekoztato adat, kb. mint a df eredmenye.

Az xfs quota teljesen jo, es abbol a szempontbol meg jobb is, mint fentebb emlitett szamlalo, mert nem az alkalmazasnak kell nyilvantartania, hogy eppen hol jarunk, hanem az fs megoldja ezt.

Bar meg az is eszembe jutott, hogy egy nagy particiot csinalok a /var ala (ahol az sql adatok + log-ok + a file-ok vannak), es csak a particio meretet mutatom meg a df alapjan. Mert az nyilvan hasznos info, hogy hany GB levelunk van, de lehet, hogy az is eleg (jo), ha a /var kihasznaltsagat megmutatom. Ez annyiban jobb, mint az xfs project kvota, hogy barmilyen fs (es igy barmilyen unix) alatt mukodik. Meg alszok ra egyet...

Palgium