Adott egy fájlrendszer, amin van több, mint 15 millió apró fájl. Jelenleg ext3, mert bevált és stabil.
Éjszakánként azonban rákergetek egy rsync-et, backupolás céljából. Mivel a fájlok többsége nem változik, így tényleges másolás szinte alig történik, viszont a könyvtárlista készítése (fstat) több óráig is eltart, amíg veszettül seekel a diszk.
Ha van valakinek valami ötlete, hogy hogyan lehetne optimalizálni ezt a folyamatot, akkor nosza, mondja!
Oké, nyilván, az SSD egyfajta megoldás, mert nem kell rajta fejet pozícionálni :)
Pl. valami olyanra gondoltam, mint a FAT fájlrendszer, hogy a diszk elején egykupacban van a FAT tábla, ahonnan az összes metaadatot be lehetne kesselni egy szekvenciális olvasással, elvégre RAM van dögivel. (vagy, ha nem is megy egy szekvenciális olvasással, mivel minden egy helyen van, nem kell sokat seekelni.)
Hozzászólások
szedd szet a fajlokat kulon konyvtarakba, valami tulajdonsag alapjan. pl ha szamok, akkor szam / 10000 => konyvtarnev (pl 123456.jpg => 12/123456.jpg) igy csak 10000 fajlod lesz egy konyvtarban.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
félreérted a problémát, a fájlok nem egy könyvtárban vannak, hanem "rendesen" szétkönyvtárazva.
15 millió objektum fájlrendszernek már lehet, hogy sok (az...), de ha belapátolod az egészet egy adatbázisba (BLOB), akkor ott azért sokkalta egyszerűbb lekövetni a változásokat.
stimmt, de a kiinduló állapot egy fájlrendszer, ez adottság. ha nincs olyan filerendszer, ami a metaadatait SQL-ben tudná tárolni, akkor továbbra is ott vagyok, ahol a part szakad.
Ha ez tényleg akkora probléma, a következő megoldási lehetőségek biztos nyitva állnak előtted:
- snapshottal backupolsz, ez a legegyszerűbb
- csinálsz egy LD_PRELOAD-os buta kis libet, ami a módosításokat lelogolja, így a backupnál nagyon gyorsan fogod tudni, hogy mit kell menteni. Hátránya, hogy minden alkalmazáshoz hozzá kell menet közben tölteni, vagy eleve bele linkelni. Ez is OS független.
- ha linux, használhatod erre az inotifyt -vagy az fsnotifyt, ez linux, bazmeg, újraírják hetente, az már ha minden igaz használható ilyenre is- (vagy bsd-ken a kqueue-t, esetleg az audit frameworköt), készíthetsz saját programot, vagy nézhetsz kész kódot példának, vagy -ha alkalmasak- közvetlen használatra is, pld. http://code.google.com/p/lsyncd/, http://ebalaskas.gr/blog/?page=PIrsyncD
suckIT szopás minden nap! WTF, FBI-backdoor az OpenBSD crypto frameworkben?!
> csinálsz egy LD_PRELOAD-os buta kis libet, ami a módosításokat
> lelogolja, így a backupnál nagyon gyorsan fogod tudni, hogy mit kell menteni
juj, ez eddig nem jutott eszembe, de tetszik! kössz!
Nem csak a metadata megy sql-be, hanem mindent belepakolsz - a fájlokat is. (Hint: BLOB)
Hasonló problémám van, minden 2 hétnél régebbi fájl (azóta nem módosult) archiválásra kerül (de nem törlődik a szerverről), amelyik újabb mint a legutolsó archiválás. Ez egy ~sima find-ed megoldható, viszont végignyálazza az összes fájlt az utolsó módosítási dátum alapján, ha ehhez lenne egy index sokkal gyorsabb lenne. Szóval ha van ilyen lehetőség fájlrendszer szinten, az engem is érdekelne.
Mivel Samba megosztásról van szó a fájlokat nem rakosgathatom saját ízlésemnek megfelelően :)
Probalkozz (hard) linkekkel, azt oda rakod, ahova akarod.
tompos
Igen, de nem lesz automatikus. Tehet minden alkalommal meg kell keresni, hogy mely fájlokhoz nincs hard link, így ugyanott vagyok.
A legjobb egy olyan index lenne ami a változás dátumát és egy útvonalat tartalmazna. Nem lehet valahogyan bele hook-olni a fájlmódosítás menetébe, úgy értem fusson le egy script ha a fájlrendszeren megváltozik egy file?
Erre tényleg célszerű könyvtárakba szétszervezni a dolgot:
1. lépésben azt keresed ki, hogy melyik könyvtár változott,
2. lépésben a gyanús könyvtárakban keresed ki fájlokat
Ha tényleg rengeteg fájl gyűlt össze, célszerű a szétszedés után egy defragni, kevés változtatás esetén sokáig egyben lesz.
...
Jobban belegondolva: amikor a seek viszi az időt, minden bontogatás nélkül is segíthet egy fs -> .tar -> fs kör.
Néhány random ötlet: Nem lehet a blokkméret változtatásával növelni a teljesítményt? Vagy betenni még egy-két diszket, hogy nőjön az IOPS? Memóriába tenni a fájlrendszert?
+1 a blokkméretre, tunefs a barátod. Meg érdemes memóriát rakni a gépbe (a linux alapból minden szabad memóriát winyócache-nek használ)
a blokkméret növelése a rendelkezésre álló inode-ok számának csökkenésével jár együtt...
nyilván a további diszkek berakása a raidbe növeli az IOPS-t. nem feltétlenül gazdaságos megoldás, már most is sok a diszk...
A durva sok fájl durva sok fájl lesz, akárhogy rakod őket sorba (persze ha van egy 15m*(kis_fajlmeret)-méretű ramparkod, akkor az se baj) -- de nem lehet megcsinálni okosba', valami logból, illetve ha olyan nincs, nem lehet a fájlokat piszkáló programot rávenni, hogy csináljon olyat?
A szerverunkon be van allitva, egy
utan egyetlen egy bitet sem olvasott a diszkrol (a
szerint), pedig 9.9 millio file van a filerendszeren.
Ehhez az kell, hogy az entryk a két felhasználás között ne essenek ki a cache-ből...
suckIT szopás minden nap! WTF, FBI-backdoor az OpenBSD crypto frameworkben?!
ha nem is rögtön 1-re, de csökkentem a default 100-as értéket. az mrtg hamarosan beszámol róla, volt-e értelme.
köszi a tippet.
(ja, és üdv, netware-t használó kolléga :) - /me netware user és supporter netware 2.0 óta)
En 3.11-gyel kezdtem, ~7 eve mars_nwe-t nyomok, lassan azt is megszuntetjuk terminalszerverre valo atallas miatt - kb. 10-szeresere sikerult felgyorsitani az ugyviteli rendszerunket.
Ez nalam egyszeru, mert tobb memoria van a gepben, mint adat a diszken... :-)