Mappánként sok apró fájl tárolására melyik a legalkalmasabb filerendszer?

Üdv!
Mappánként sok apró fájllal kéne dolgoznom. A sok alatt 1-2 millió fájl értendő, az apró alatt meg 100byte - 10kbyte. Arra már rájöttem, hogy az ext4 erre nem alkalmas. A sima ls parancs is kifekszik, kb. 10-15 percig semmi életjel, azután kezdi el köpködni a fileneveket, de az is hatalmas idő lenne, míg a végére érne. (fél óra után is írja a fájlokat).
Amivel létrehozom ezeket a fájlokat, eleinte gyorsan jönnek létre a fájlok, de ahogy egyre több van, egyre lassabb.
Nekem úgy tűnik, hogy a szűk keresztmetszet nem csak a hardverben keresendő. Az ls parancsnál pl. a processzor volt 100%-on, a lemez nem nagyon kerregett.
Mielőtt nekiállok kísérletezni, kíváncsi volnék, van-e valakinek tapasztalata/megoldása ilyen problémára?

Hozzászólások

Törölve.

SSD-n lenne tárolva ?

Fedora 30, Thinkpad x220

SATA HDD-n. ...de előbb-utóbb SSD-n lesznek csinálva az ilyen dolgok, ha csak azon lehet majd ugrásszerű gyorsulást elérni.

... mondjuk, ez a cucc amivel most killódom, egész jó tesztelés is lenne egy SSD-nek :D

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Pedig csak SSD-n lehet gyorsulást elérni. Nem a fájlrendszeren múlik, HDD erre a sok kis fájlok mókára, főleg ilyen extrém mértéknél, egyszerűen nem alkalmas. Mintha floppyról, meg pendrive-ról akarnál telepített OS-t használni.

Mondanám, hogy olcsó már egy 120 gigás SATA3 SSD. De mivel nálad annyira extrém ez a felállás, már ezt is ugorhatod átfelé, az ilyenekre találták ki az NVMe-t, de még abból is egy normálisabb Optane néz ki a legjobb drive-nak erre a felhasználásra.

Esetleg ha a fájlok összmérete nem olyan óriási, és van elég RAM-od, akkor próbálhatod RAM drive-ból is használni (tmpfs).

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

mindenképpen fájlokban kell lenniük ezeknek az adatoknak? Nagyon úgy hangzik, hogy neked valójában egy adatbázisra lenne szükséged.

Javaslom, hogy vezess be almappákat. És akkor egy adott mappán belül nem lenne olyan sok file.

Tehát ha mondjuk lennének ilyen file-ok:
abc123
abc456
def123
def456

Akkor inkább így legyenek:
abc/123
abc/456
def/123
def/456

Igény szerint akár több almappa szint is bevezethető.

Attól még a kiinduló állapotban is célszerűbb lesz név alapján könyvtárakra bontva szétpakolni, aztán amikor megvan, hogy mi a tartalom alapján a végleges helye, akkor azonos fs-en belül elég egy átmozgatás a végleges könyvtárba, vagy akár egy hardlinkkel megoldani, hogy a feldolgozás előtti és utáni állapot is meglegyen úgy, hogy helyet nem foglalsz duplán.

Az ls szerintem rendezni próbál alapértelmezetten - talán név szerint? - de nem arra találták ki, hogy pár milliós adatsort sortoljon. Szerintem ezért lassú. Az ilyen feladatot pedig úgy kell megoldani, hogy többszintű könyvtárstruktúrát használsz, amit a rendezési szempontok alapján dinamikusan hozol létre. Valaki írta már ezt, erre feküdj rá szerintem.

Én is ezt akartam írni (a 100% CPU miatt), aztán kipróbáltam egy ls és ls -u összehasonlítást, 30.000 könyvtárbejegyzésig (közben folyamatosan csináltam egy másik terminálban a többit) gyakorlatilag nem volt észrevehető különbség. Mondjuk ha rosszul skálázódik, még mindig lehet gond...

A másik tippem, hogy valami hálózati forrásból akarja az uid-eket usernévre feloldani, ami sokáig tart neki...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Jogos, generálom a fájlokat és újra mérek :)

Szerk.: 14.000 fájlnál 3-szoros futási idő, aminek a kétharmadát user módban tölti... sort nélkül 0.000 a user...
Szerk 2.: 50.000 fájlnál 6-szoros, user idő tízszeres...
Szerk 3.: 100.000 fájlnál hasonló 50.000-hez, de még mindig ~0.3 sec alatt van... (ext4 sima tányéros lemezen, mondjuk itt a cache is játszik, egy millánál azt kidobom)
Szerk 4.: 160.000-nél a echo 2 > /proc/sys/vm/drop_caches-el kiegészítve is ugyanez az arány (kb. 5* real és 10* user)
Szerk 5.: ls -la és ls -laU formában van egy nagy ugrás a futási időben, és csökken a különbség (kb. 1.2* és 2*), de valamivel kevesebb, mint 200.000 bejegyzésnél még mindig 3 sec környékén járunk
Szerk 6.: 300.000, a helyzet változatlan, sima ls-el még mindig 1 sec alatt.
Szerk 7.: 580.00, ls / ls -U-val változatlan, még mindig értelmes időn belül, -l-el együtt a tízszeres szorzó már érződik (~25 sec is volt)
Szerk 8.: 738.000-nél már közelebb áll a 20-szeres szorzóhoz a user.
Szerk 9.: 1.000.000-nél

> echo 2 | sudo tee /proc/sys/vm/drop_caches > /dev/null && time ls -la > /dev/null

real    0m25.328s
user    0m4.643s
sys     0m6.209s

> echo 2 | sudo tee /proc/sys/vm/drop_caches > /dev/null && time ls > /dev/null

real    0m3.045s
user    0m2.561s
sys     0m0.418s

> echo 2 | sudo tee /proc/sys/vm/drop_caches > /dev/null && time ls -U > /dev/null

real    0m0.871s
user    0m0.248s
sys     0m0.252s

>  echo 2 | sudo tee /proc/sys/vm/drop_caches > /dev/null && time ls -f > /dev/null

real    0m0.656s
user    0m0.179s
sys     0m0.337s

Vagyis: a stat lassú, a rendezés szintén, de egyik sincs a közelében sem a fél órás időknek az OP-ban.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

ha ls -l listat csinalsz akkor az stat-ol minden fajlra, nagyon lassu lesz. amugy is az ext4 olyan 50-80k db fajlig birja jol, utana mar nagyon belassul. amugy se jarsz jol, 100 byte is elfoglal egy teljes blokkot, nagyon nagy lesz az "ures" veszteseged.

akkor mar inkabb pakold valami db-be. ha csak olvasni/irni kell, akkor nemkell mysql vagy sqlite, siman jo valami keyvalue (pl leveldb) store is

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

ext4 largedir opciója nem segít? Állítólag több szintű fával indexel. Amúgy én sem fájlonként tárolnám.

xfs kicsit tuningolva. Anno zoneminder alatt használtam, ahol minden képkocka egy fájl. A törlés lassú, többi művelet oké.

Az xfs-t kipróbáltam, úgy tűnik, ez lesz a megoldás.

simán, tuningmentesen "mkfs.xfs -f /dev/sdb1" paranccsal létrehozva:
kb 200000 fájl után kezd egy picit lassabb lenni, de alig észrevehetően. Az ls, sőt még az mc sem gondolkodik sokat így. (az ext4 már 25000 fájl környékén lassult, 100000 fölött meg már szinte használhatatlan volt. A journal kikapcsolása is csak egy picit javított rajta)

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Tehát optimálisan fut az ls.
Hurrá!

Most már csak a következőket kellene kitalálni:
- Fogod-e futtatni az ls-t vagy sem?
- Vagy inkább a find lesz a jó, és tökmindegy milyen gyorsan fut az ls? ;)
- Az NxM struktúrába rendezés biztosan felejtős, - annyira lassú lehet - akkor meg mi legyen?
- Vajon ki kell-e írni a fájlokat, és ha igen akkor minek?
- Neki is állhasz az 1-2 millió fájl megnyitásának és olvasásának optimalizálásához. (Mivel az ls már optimális.) Vagy nem is így kellene megoldani?

Egyelőre ennyi is elég.

... leginkább c program fog végigfutkosni a fájlokon, aztán majd valahogy rendszerezve lesznek, de biztos nem NxM struktúrába.
Alapos vizsgálat után már adódott is egy lehetőség, hogy (talán) a legérdemesebb fájlméret alapján szétválogatni.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

A fájlokat meg is kell őrizni vagy csak átmenetileg hozod őket létre valamilyen feldolgozási folyamat során?
--
eutlantis

Nem kell hosszútávra megőrizni, csak amíg agyalok egy programon. Ha kész lesz, valószínűleg nem is lesz szükség ilyenfajta feldolgozási módszerre sem.

(Murphy 26. törvénye: amikor elkezdesz csinálni valamit, rájössz, hogy előtte még valami mást is csinálni kell :D )

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Vagy, ha ez a felállás, akkor minek a millió apró file? Akkor tényleg tolja bele a programja valami db-be, ahol azután úgy indexel, ahogy neki tetszik. Az ilyen ezer apró file-os szarakodást én csak akkor tűröm el, ha külső forrásból jön az input, amire nincs ráhatásunk. De előállítani ezt az állapotot...persze ki hogy akar szívni, az egyéni dolog. :D

Így kezdi: Mappánként sok apró fájllal kéne dolgoznom. A sok alatt 1-2 millió fájl értendő, az apró alatt meg 100byte - 10kbyte. Arra már rájöttem, hogy az ext4 erre nem alkalmas.

Tehát KELL. Azt gondoltam, nincs választása, de van. Csak rosszul választott. :)

Van tapasztalat ilyesmi téren. > 900k aprófile van egy-egy könyvtárban. Természetesen ls elfekszik rajta, de nem a sebességre gondolok, hanem "Error: Argument list is too long" hibát dob az ls. :-)

Az ls teljes mellőzésével is szépen el lehet boldogulni.

find parancsot kell használni ezeken a könyvtárakon, gyorsabb mint az ls nincs felső darabszám limit.

Pár példa:

Beleállsz cd-vel az aprófileos folderbe (vagy absolute path-ot használsz), majd ls helyett find paranccsal tudsz listázni:

find . -type f -name "*.csv"

valami alapján törlés, pld filenév alapján januári fileok :
find . -type f -name "201901*.txt" | xargs rm -f

600 napnál régebbi fileok tarolása:
find . -type f -mtime +600|xargs tar -rvf /tmp/oldshit.tar

két időpont között keletkezett fileok megszámolása:
find ./ -type f -newermt "2018-06-01 00:00:00" -not -newermt "2018-06-20 00:00:00"|wc -l

greppelés, melynek kimenete filenév:keresőszó-t tartalmazó sor, tehát lehet awk-val vagy cut-tal ":" delimiternél a fileneveket kitermelni.

find . -type f -name "*.csv"|xargs grep "keresőszó"

A "find ... -mtime...| xargs rm..." mókára nekem volt tapasztalatom RHEL5/6 alatt - mondjuk úgy, hogy erősen szuboptimális volt a stat()/fstat() rendszerhívások számát tekintve - is, úgyhogy megírtam Perl-ben: dir megnyit (egy open), fájlok listáján végigmegy, ha mintára illeszkedik, akkor mtime-ot néz (egy fstat), és ha régebbi, akkor unlink.

Egy mappában tényleg belassul a rengeteg fájl kezelése, ez adottság. Elég arra gondolni hogy például létrehozáskor is meg kell vizsgálnia, hogy nincs-e ilyen nevű bejegyzés már az adott mappában, amihez
- vagy egyesével kell összehasonlítani a millió meglevő fájllal, azért lesz nagyon lassú
- vagy közelítő kereséssel (log N) kutatja fel, hogy van-e azonos, amihez rendezett listát kell állandóan újraírni.

Tulajdonképpen mi gátol meg abban, hogy kétkarakterenként szétszórd almappákba?

Pl.
a59f8d.log
fdc0a5.log

szétszórva:

a5/9f/a59f8d.log
fd/c0/fdc0a5.log

Ebben a példában a hexadecimális nevekkel 256 bejegyzés/mappával lefedted a 16 millió fájlt.

Igen, sokszor lattam mar ilyen elb@szott designt.
Tervezd at a programodat, ezt semmilyen filerendszer nem viseli el.
Barhol probalod majd uzemeltetni el fognak kuldeni a francba.
Talalj ki normalis mechanizmust arra hogy egy mappaban ne legyen tobb par tizezer file-nal. A meretuk nem szamit.

Ilyenkor szotam bedobni, vajon hogyan tárolok 35M fájlt (vagy bármennyit) 0 hozzáférési idővel, diszk és fs függetlenül. Eddig még csak lehülyéztek érte. De a fiatalságé a jövő, nekik is kell tanulni, kísérletezni. Csak abból nem mindig jön ki az optimális megoldás. ;)

A tízezer egy jó szám, de minek annyi?

Naugye! Mondtam előre, hogy jön a sok okostojás és le fog hülyézni. :)
Pedig az egyszerű mondatok értelmezése is problémát okoz. :(

A diszk és fs függetlenül nem egészen azt jelenti, hogy vödörben vagy polcon, esetleg széfben tárolok valamit. :-D Mindössze annyit, hogy nem kell olyan elméleti megfontolásokat tenni, mint fentebb: Hurrá az xfs az optimáls! - Bár tán nem tudjuk mire, de az biztos, hogy az ls gyorsabban fut rajta. Na és?

Tehát a diszk és fs függetlenül jelentése csak annyi, hogy a sebességet lényegesen nem befolyásolja sem az alkalmazott diszk, diszk alrendszer vagy fs milyensége sem.

A 0 hozzáférési idő sem abszolút nulla. ;)
Vegyük alapul a fenti xfs+ls idejét, felkerekítve 1s időre.
Ezzel szembe lehet állítani az én indexelt tárolási módszeremet. Ha az indexek memóriába kerülnének, akkor egy bonyolultabb lekérdezés 220ns (Volt 15 évvel ezelőtt. :)), amit felkerekítek 1us-ra.
Ennek alapján a megoldásom futásideje 0,0001%-a a másik megoldásnak, ami legyen ~0%.

Mindkét megoldásnál először tárolni kell a fájlokat. Mivel nálam a tárolás pillanatában az index is keletkezik, ezért a végleges futásidő az ls-hez képest nem 0, hanem negatív lesz. :-D

A hozzáférési idő pedig egy open() és egy seek() ideje. Abba már bele se megyek, hogy ez nálam miért fog gyorsabban lefutni. ;)

A válasz nem egyértelmű, hiszen nem célom leírni azt a néhány, különböző célú és adattartalmú rendszert, amit eddig csináltam.

Tehát: A fájlok tárolása igen, diszken, de optimalizált méretű konténerekben.
Az indexek tárolása változhat, mert egy tárolót az adatmennyiség, a hozzáférések száma és gyakorisága jellemez. (Ezt nem én mondom, hanem egy japán szakember, aki egy elemzés alapján 1987-ben extrapolálta a jövő tárolóit is. Szerintem 50 vagy 100 év múlva is helytállóak lesznek az akkori megállapításai.)
Tehát: Az indexek tárolása, ha csak ritkán kell egy-egy fájlhoz hozzáférni, akkor elegendő fájlban. Ha gyakori, vagy nagymennyiségű hozzáférés az igény, akkor memóriába lehet tölteni. A felhasználó egyik esetben sem fog várakozni.

Mivel ez egy 11 éve működő, elég extrém terhelésnek kitett rendszeren fut, nincs side effect sem. Tehát lényegtelen a rendelkezésreálló memória mennyisége, és a futó processzek száma is. Szóval ez egy szerver és nem egy laptop, ahol van 32GB az ls eredményének tárolására. ;) Persze ez is volt a cél.

Az egyik konkrét felhasználás az, amikor a fejlesztők 140 szerver tizenvalahány logja közül kiválaszt egyet, meg egy intervallumot az elmúlt 90 napban. Kattint és megjelenik. A logok néhányszor 10B - max. 128MB méretű fájlokban érkeznek a backupba. (Na, azért az utóbbi méret csak akkor igaz, ha valami baleset volt.) Ennek az előszedése nem kritikus, mert jóval rövidebb, mint amennyi idő alatt a kattintás beér a szerverre. Ha több száz fejlesztő dolgozna egyszerre, akkor az indexeket be kellene tölteni.

Amit te leírsz (nem path, hanem egyéb kritériumok szerinti keresés), az egy adatbázis use case. Ezt ezerféle rendszer tudja minimális hozzáférési idővel hozni, fájlrendszerek pedig nyilván nem, mert nem arra vannak kitalálva. Ha tényleg csak fájl elérésről lenne szó path szerint, azt egy fájlrendszer is gyorsan hozza (mert egy jó fájlrendszer modulja is használ indexeket a könyvtárakban és cache-elést).

Minden betűd igaz.
Még csak azt kellene leínod, hogy melyik adatbázis az, amelyik pl. 10000 entry-t egy művelettel kiolvas. Ehhez fel lehet használni egy open(), egy seek() és egy read() hívást.
Nyilvánvalóan a fájlrendszeren ez 10000 open() és read() (és mivel sok, ezért close() is) lenne. Ehhez persze ugyanennyi direntry-t is fel kellene olvasni, indexelve, cache-elve.

Vessük össze a topicnyitó megoldással!
Létre kell hozni 1M fájlt és kiírni. Én is ugyanezt teszem, csak kb. 10 konténerbe. Fogadok, hogy az ls is gyorsabban fut rajta. ;) Persze semmi ilyesmit nem kell tennem, mert +1 indexet is írtam, így már 11 fájlom is van!
Az "use case" akármi lehet. Én éppen catolok, de lehetne az egyes fájlok karaktereinek összegéből köbgyököt is vonni.
A topicnyitó az 1M fájl feldolgozása után szeretné azokat egy NxM struktúrába válogatni. (Ő írta.) Az ilyen roppant lassú szokott lenni. Én meg legfeljebb az indexet módosítom.

A műveletek sebessége egy sql adatbázishoz képest bizonyítottan 3-4 nagyságrenddel gyorsabb. Ha az indexeket BerkeleyDb-vel kezelném, az csak 2-4x lenne lassabb. ;) Az erőforrások mennyiségéről ne is beszéljünk!

Én ide csatlakoznék, több archiváló szoftver, vagy diszk alapú archív tároló, vagy nagyvállalati NAS, konténerben tárolja az apró fájlokat. Így kisebb az overhead a kezelésnél, hatékonyan tárolható paritásos védelemmel egy nagyobb fájlba csomagolva őket. Igaz ebben az esetben az olvasás lassabb, mivel a fájlrendszeren túl, még a konténerből is ki kell szedni.

Gyakorlati tapasztalat, sok email (~130 milllió) 135000 darab 100MB konténerekben kb. 13TB, másolása 2x1G Etherneten keresztül volt, ~1 nap, addig 90 millió apró fájl ~1TB 1,5 hét volt a másolási idő. 

Részben lásd a fenti válaszomat!
Tájékoztató jelleggel: A file tárolható blob-ban, adatbázisban, tömörített fájlban, tape library-ban, meg még rengeteg helyen. Ha az adatbázis netalántán raw volume-ot használ, akkor meg filerendszer sem igazán van. Tehát a file ilyenkor nyilvánvalóan kisnyúlon tárolódik. :-D

Szóval ilyen határozott kijelentéshez minimum ismerni kellene a vfs fogalmát!

Képzelj el egy olyan absztraktciót, amikor a "cat joke.txt" parancs hatására a vfs driver kiírja a titkárnő monitorjára, hogy "Julcsa! Vedd le a 3. iratgyűjtő szekrény 2. polcáról az 5. mappát és gépeld be a 20. oldalt!" - Előtted meg fog jelenni a joke.txt. No, ez egy vfs driver. :-D

Tedd sqlite adatbázisba.

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Én maradnék ext4 + mappákba rendezve és mint fent kiderült nem ls-sel listáznék.

Sakk-matt,
KaTT :)

xfs vagy btrfs

Ext4-nél a szabad inode-ok is érdekesek lehetnek, képes megtelni hamarabb, mint maga a diszk.
A fájlokat érdemes több almappába pakolgatni, mint pl squid is teszi a cache-el.

Én úgy szoktam, hogy a fájlok neveit felbontom, vagy a fájlok md5-jét bontom fel mappákra és pl. az első 5 karakter egy mappa, a következő 5 egy másik almappa stb...

----------------------------------------

SELECT * FROM World WHERE "Someone" LIKE '%You%';
----------------------------------------
o.-

Jaj de jót szoptam egy ilyennel nemrég. Grafikus csóka egy mappába bele gyűjtögetett vagy 1,2mill. db képet hátha jó lesz alapon. (bevallása szerint 5 évi meló 0,5-5MB méretig)
Nyilván, összehányta magát a rendszer. Valami live linuxal sikerült hozzáférnem, kb.1000-1500 file -t tudtam egyszerre megmozgatni. Ráment 1 napom mire szétszedtem a kupacot. Én azt vettem észre, hogyha almappákba vannak akkor is furán instabilan működtek a fájl műveletek. Bár ez lehet, hogy Win filekezelési hiba, nem partíció típus, mert Linux alatt elég fürge volt így már. (bár NTFS nem oda való)

mivel nálam egy könyvtárban kell lennie a fájloknak (képes, filmes projekt) csak is xfs

  • ext4 8-9000 fájl után már lassulást, és Nautilus halált okoz
  • xfs 100.000 kép esetén sincs lassulás, a Nautilus kicsit gondolkodik
  • szerintem ha elérem a 400.000 kép/mappa sem lesz gond

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Nem végleges tárolás, csak átmeneti munka mappa és valószínű nem is marad így. Kissé nehézkes a feldolgozás:)

Eszembe jutott a topic címe, mert valóban az ext4 nagyon nem szerette.

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Láttam én anno temp könyvtárat, amiben a takarításhoz névre illeszkedő mintákra és a módosítási időre paraméterezett find nem futott le emberi idő alatt... Aztán lett helyette egy perl script, ami csak az illeszkedő névvel bíró fájlokra hívta a stat() -ot, és rögtön nem volt gond a futási idővel :-)

Ezt azért nem értem, egy

find . -name lof\*sz.jpg -mtime +3

parancsnál nem fog lefutni a stat csak ha illeszkedik a név - azaz szükség van a következő feltételt is vizsgálni. (Már persze értelmes find implementáció esetén; valamint gondolom én.)

Már csak az a kérdés maradt, hogy az RHEL5 vagy 6, a find és a stat() hívások számának mi köze a feladat megoldásához? ;)

Ilyenkor néha bedobom, hogy a 12 éve működő rendszerem ebben a pillanatban 37.560.074 ojjektumot tárol és legalább 2-3 nagyságrenddel gyorsabb, mint egy sql adatbázis, bár ezt fs függetlenül tudja. Aztán lehülyéznek, de hát ilyen az élet. :(

Az a köze, hogy ha sz@rul optimalizálja a find a feltételeket, akkor 1M fájlra ~4M erndszerhívást csinál, miközben jól optimalizálva ennek töredéke elégséges -ami futási időben khm. nagyon észrevehető különbség.
A topic szempontjából meg azért releváns a példa, mert nagyon nem mindegy, hogy az az alkalmazás, ami használni fogja az egy könyvtárba beleokádott fájlokat, az hogyan csinálja a fájlkezelést (létrehozás, keresés, megnyitás, törlés)? Nagyon nem mindegy ugyanis.

Ha már ragaszkodsz a find használatához, akkor igy kell optimalizálni a feltételeket: find. Ez optimalizálja legjobban az összes feltétel, tehát egyben a leggyorsabb is. ;)

Aki 1-2 millió fájlt egy helyre ír, az nem igazán gondolkodik. Ez alól egyetlen kivétel van, ha fájlkezelőt kell írni. ;)

Ugyanezt NxM struktúrában tárolva végképp öntökönlövés.

Optimális megoldás az adatbázis, amihez még az adatbázist is futtatni kell. :-D Hiszen a fs is egy adatbázis kezelő rendszer, de pont arról szól a topic, hogy nem optimális. Ha erre még ráraksz egy csomó rendszerhívást, akkor biztosan optimálisabb lesz! És akkor miért is kellene egy nem optimális adatbázisban még keresgélni is?

Ha a fentiekből nem az jön ki, hogy NEM fájlkezeléssel kell megoldani a feladatot, akkor olvasd el mégegyszer!

Persze azt sem vettük figyelembe, hogy bárkinek a laptopján végtelen sebességű kernel fut, végtelen memóriával, ami a tetszőleges számú inode olvasgatásra optimális, ezért 0 idő alatt végzi el. A rendszerhívások valamilyen adaton dolgoznak, amely azonnal ott is terem, ha szükség van rá. Ha nem pont így van, akkor érdemes még egy kicsit gondolkozni! ;)

Nem ragaszkodtam hozzá - örökölt rendszer volt, és meg kellett oldani, hogy működjön a takarítás - a find helyett egy adott feladatra összerakott perl script készült, ami a find futási idejéhez, illetve az általa okozott terheléshez képest nagyságredileg kedvezőbb volt, Hogy azóta mi lett az adott motyóval, nem tudom, de tippre kivezetésre került.

Hülyén hangzik, de az NTFS-t próbáltad? Szégyellem leírni, de manuális kereséshez nálunk az vált be, Windows 7 fájlkeresővel hasonló feladatra.

Szerkesztve: 2020. 04. 02., cs - 23:20

ha te irod a progit akkor rakd leveldb-be a "fajlok" adatait, aztan o majd letarolja szepen es jol, es bizonyos muveletek gyorsak is lesznek.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hülye kérdés, az ext4 ugyanúgy "indexálja" alapértelmezetten a fájlokat, mint a Win?

Biztos vagyok benne, hogy nem erre gondol. Írta, hogy olyan indexálásra gondol, mint Windowsnál van, ami a fájlokat is beindexeli. Ez a dir_index meg nem indexeli az összes fájlt, csak a mappákban lévő keresést gyorsítja fel. Annyiból viszont nagyon jó ötlet, hogy ezt szóba hoztad, hogy megérné megnézni a topikindítónak, hogy ez a dir_index be van-e kapcsolva (default be kéne lennie), a dumpe2fs paranccsal tudja megnézni, ha nem lenne fent (amit eléggé kétlek), akkor az e2fsprogs csomagot kell feltenni hozzá.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Nem, nem indexálja alapból. Egyik fájlrendszer se. Windowson se. Ami indexel, az egy fájlrendszertől külön szolgáltatás. Windows csak annyiból speciális, hogy ott alapból be van kapcsolva. Linuxokon disztró meg DE függvénye. Nagyobb asztali környezetekben be lehet kapcsolva, pl. KDE, de egyébként Linuxon nem szokott ilyen bekapcsolva lenni. Illetve DE-től függetlenül is használható indexelő szolgáltatások Linuxon, pl. mlocate, aminek kézzel kell frissíteni (újraindexeltetni) az adatbázisát, de ennek eleve opcionális a telepítése, meg rajtad függ az indexelése is, szóval nincs olyan, hogy véletlenül tudtod nélkül be van kapcsolva.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Ugy latom senki sem irta. Az ls azert lassu, mert alapertelmezetten rendezi a file-okat, igy ertelemszeruen eloszor be kell olvasni az osszeset, aztan tudja elkezdeni kiirni.

Pici man ls es kapcsold ki a rendezest, akkor elvileg azonnal el kell kezdenie fosni a file-okat.

 

SQL-t en kihagynam, egy mongo cluster kivalo erre, a document storage-t pont erre talaltak ki, es skalazodasa gyakorlatilag linearis erre a celra.

Ha javasolhatom, a POSIX szabványban is szereplő -f opciót kéne preferálni, nem pedig a GNU-specific -U -t. (Másként mondva: -f máshol is van/lesz, -U máshol vagy van vagy nincs, vagy mást jelent vagy ugyanazt.)

xfs-t csak akkor ha nem kell letorolni a fileokat :)  az valami isoznyat lassu xfs-nel.

en reiserfst hasznalok ilyesmire (pl maildir sok millio levellel), de talan a btrfs is van mar olyan jo.