konyvtar merete (sok file van alatta) hogyan?

 ( sj | 2012. február 10., péntek - 12:15 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

igen. Az ok egyszeruen az, hogy egy hatar felett elfogadhatatlanul lassu, mire eredmenyt latok

Palgium

Gondolom a /mnt/a féléből véges számosságú van, mondjuk a..z. Ha fontos a sebesség, akkor lehet mind külön-külön mountpoint, és df. Bár még szoknom kell a gondolatot, hogy csak ezért ilyet tenni.

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

ha lehetseges a kod beepitese

lehetseges, hirtelen egy sql update meret=meret+x jutott eszembe. Kossz a tippet.

Palgium

Vagy pl. gamin használata?

Jol gondolom, hogy az inotify alapu? Mert akkor a sok konyvtar eseten az indulas katasztrofalis sebessegu lehet... (Igen, lusta vagyok elolvasni; masreszt viszont aki inotfy -t javasol annak ezt is figyelembe kell vennie).

Igen, Linux alatt inotify alapon megy. A kiindulási állapot "felméréséhez" másra van szükség.

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

Ez is egy kvótás javaslat lenne, csak más megközelítésből. Ha nincs ellenérzésed az XFS-sel szemben, akkor azon a project quota (pqnoenforce) azonnali eredményt ad.

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

es hogy kene latnom a riportot? Mert pl. az alabbi csak siman visszaadja a promptot:

xfs_quota -xc 'report -h' /

ja, elotte reboot-oltam a gepet (egy teszt VM-rol van szo), es azelott az fstab-ba beirtam a / mount opcioihoz a "pquota,prjquota,pqnoenforce"-t.

Palgium

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.

megvan. Annyi a trick, hogy nem a root fs-en kell csinalni. Kossz a kimerito segitseget ;-)

Palgium

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.

megnezem majd ezt is. Btw. van meg olyan fs, ami tamogat egy ehhez hasonlo feature-t?

Palgium

Szerintem ilyen adathalmazokat érdemes külön partícióra tenni.

Egyébként meg: mérd meg a kevesebb fájlt tartalmazó adathalmazt (SQL), aztán a volume méretéből és a szabad helyből ki tudod találni a nagyobb méretét.

--
joco voltam szevasz

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

tudnal benchmark eredmenyeket mutatni, hogy pl. 3 millio file eseten ez mennyi ido alatt fut le, szerinted? ;-)

Palgium

A "baromi sokára" elég pontos? :-P

igen, az. Kilove :-)

Palgium

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

---
debian squeeze

egyszerunek ugyan egyszeru (eddig ok), de mennyi ido alatt lesz kesz?

Palgium

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

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

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

"a tarolt levelek meretet mutatna meg, azaz hogy pl. 300 GB van az archivumban"

Napi egy levél a usernek, ha átlépte kvótát? (nincs valós kvóta az fs-n, csak számlázott -gondolom ez lenne az igény-)

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