Dotaz: Velké množství souborů vs. souborový systém

[jan.rok]

Rád bych přesunul poštovní server Kerio Connect z Windows Serveru na linux (Debian nebo Redhat jsou podporované). Důvodem je výměna hardware. Poštovní server obsahuje mailboxy, které mají velké množství souborů (co mail, to soubor) a práce z klientem Outlook je již velmi pomalá. Je to asi zapříčiněno tím, že maily jsou povětšinou v několika málo složkách a počty jsou opravdu velké (typicky až 100 000 mailů např. v Doručené poště). Zajímalo by mě, který souborový systém by si s takovou hrůzou poradil nejlépe?

Samozřejmě nejschůdnějším řešením je donutit uživatele poštu více segmentovat, ale z mnoha důvodů (lidský faktor a byrokracie) to nelze.

Moje otázka je tedy spíše teoretická, protože podobná situace může nastat třeba i při sběru nějakých dat, kdy program zapisuje data do mnoha malých souborů a práce s takovým objemem pak začne být nepohodlná.

Jak se to tedy vlastně řeší? Někde jsem četl, že třeba NTFS začne mít výrazné problémy při víc jak 3000 souborech ve složce.

Díky za názory. JR.

Odpovědi

[Kit]

Podle mých zkušeností si s takovým množstvím souborů skvěle poradí ReiserFS (který na to byl navržen) i Ext4.

[V.]

Dík za připomenutí, že pořád stojí za to zůstávat u reiseru

[dustin]

Také máme v maildiru běžně 100k mailů/souborů, pro server mi to nepřijde nijaká zásadní zátěž (dovecot/IMAPS). Běží na XFS, mdraid10, samozřejmě dostatek paměti, aby si jádro drželo strukturu adresářů v keši.

[Jurasek]

Zdar,

jak to pak zalohujete, kdyz mate treba 1TB posty v maildirech co maji 100k mrnavych souboru ? Myslim nejaky zalohovaci SW /Bareos,NetWorker/ jake je casove okno zalohovani, kdyz se delaji treba inkrementalni zalohy a porovnava se co je v zaloze a co na disku.

Dik a zdar.

Jura

[MP]

Obecne spatne. Na neco takoveho je incremental MUST HAVE (idealne Always Incremental) a pripadne to podporit SSD. Nebo snapshoty. Jina cesta neni.

Z hlediska casu a vykonu je nejlepsi metodou snapshoty na urovni. U nas se zatim pouziva Bareos a full trva pri ~350GB na 8xSAS raidu cca 10h...A v jednom adresari jsem nasel i 500k souboru...

[dustin]

Již 15 let obyčejným backuppc. Je pravda, že neumí vyřešit změny maildiru během zálohování (nemá snapshoty a časové zálohovací okno je poměrně dlouhé), ale ještě se mi nestalo, abych smazaný mail v zálohách nedohledal.

Dneska bych již nic jiného než ZFS na nový server nepoužil. Bohužel většina našich instalací je legacy, tam se musí postupně

[jan.rok]

Samotný server s tím množstvím problém nemá, spíš klient (Outlook).

Záloha běží denně rozdílová (to trvá chvíli) a pak o víkendu full backup (to je asi kolem 8 hodin). Vše zajišťuje Kerio Connect sám (myslím, že je to nějaký zip na NAS, celkem asi 400 GB).

[dustin]

Taky bych si tipnul, že urychlením serveru nepořešíš pomalého klienta.

[Pavel 'TIGER' Růžička]

Outlook je mula líná, protože pst. Přes to vlak nejede. Obdivuji firmy, kde jej používají.

[GeorgeWH]

Ja som mal s XFS a mailovym serverom problem. Presuvanie radovo uz 100-viek mailov v Roundcube mu trvalo dlho. Po prehodeni na ext3 to uz bolo ok. Pokial sa dobre pamatam, tak XFS je vhodne skor na velke subory ako na male.

[Peter Golis]

Kedy, v ktorom roku si prosím ťa použil ext3, a nie ext4?

Bez urážky, len či sa jedná o aktuálnu skúsenosť a nie o nejakú spomienku z mladosti z pred 10 rokov.

[GeorgeWH]

Ano je to uz par rokov, ale zrejme je to stale aktualne.

https://unix.stackexchange.com/questions/28756/what-is-the-most-high-performance-linux-filesystem-for-storing-a-lot-of-small-fi

https://www.unidata.ucar.edu/mailing_lists/archives/ldm-users/2016/msg00161.html

[Peter Golis]

Pýtal som sa že prečo EXT3 a nie EXT4, a doplním že EXT4 bol prehlásený za stabilný pred desiatimi rokmi. V tvojich linkoch som nikde nevidel spomenúť EXT3. A navyše, ak máš fragmentované súbory, tak budeš limitovaný IOPS blokového zariadenia a veľkosťou diskovej cache (vrátane RAMky s baterkou na radiči). FS s tým veľmi nepohne, ak ho nejakým spôsobom nedefragmentuješ. Kľudne aj migráciou na nový mountpoint ako si to urobil ty.

[Milan Lasica]

Pýtal som sa

Jen to Peter asi neprešlo pres hranice.

[Semo]

Ext3 je tiez stable a pri malych suboroch pravdepodobne ani nevyuzijes Ext4 efektivnejsi sposob alokovania miest cez extenty. Takze si myslim, ze na mailserver nie je Ext 3 ziadnou chybou, hoci nie je jedinou volbou. (A ja osobne by som tam dal ReiserFS).

[Aleš Kapica]

Jsou situace, kdy je ext3 rozhodně lepší volba než ext4.

[Peter Golis]

Mňa to zaujímalo z časového horizontu.

To že sú situácie keď je lepšou voľbou dokonca EXT2 je tiež pravda, až pokiaľ nie je treba spustiť fsck ktorý už bez žurnálu moc nefunguje. Už som sa na tom spálil.

[Chulda]

To by mě zajímalo kdy, když se bavíme o velkém množství malých souborů v adresáři.

Skoro 1mio malých souborů v jednom adresáři na ext3 spolehlivě zaměstnalo server na 8h při fsck (SAS). Přesun na SSD to zlepšil, ale pořád šlo o hodiny (přičemž pokud jde o IOPS, tak SAS měl tisíce a SSD deseti tisíce)

Ext4 už byla výrazně rychlejší (tuším šlo o pár desítek minut na SSD, ale už nešlo o stejné podmínky)

Kdysi jsem měl link, který porovnával identickou situaci na ext3 a ext4 a rozdíl byl skoro řádový.

[alkoholik]

To zni skoro jako chybejici dir_index.

[Peter Golis]

A ten bol až v EXT4.

[alkoholik]

Ne, nebyl. Chces se hadat nebo rovnou priznas, ze tu vesis novackum buliky na nos?

[Peter Golis]

citacion needed.

[alkoholik]

UTFG

[Peter Golis]

Vo východzej konfigurácii? Nie, to bolo vo východzej konfigurácii zapnuté až v EXT4.

[alkoholik]

A o vychozi konfiguraci tu mluvil kdo?
Uz si vzpominam, proc mam Golise mezi zablokovanymi. Mele kraviny.

[alkoholik]

BTW: Pro Debian:
What are the default option for Ext3 partitions in Lenny? ext_attr resize_inode dir_index filetype sparse_super large_file (See /etc/mke2fs.conf. Read the docs for the flags meaning)

[Peter Golis]

A spomínal tu niekto že mu to pred neznámym počtom rokov nefungovalo s dostatočnou rýchlosťou na XFS, ale že mu to išlo po mmigrácii na EXT3?

Skús si nabudúce prečítať na čo reaguješ.

[alkoholik]

O cem je tohle vlakno?

Skoro 1mio malých souborů v jednom adresáři na ext3 spolehlivě zaměstnalo server na 8h při fsck (SAS). Přesun na SSD to zlepšil, ale pořád šlo o hodiny (přičemž pokud jde o IOPS, tak SAS měl tisíce a SSD deseti tisíce)

Ext4 už byla výrazně rychlejší (tuším šlo o pár desítek minut na SSD, ale už nešlo o stejné podmínky)

Kdysi jsem měl link, který porovnával identickou situaci na ext3 a ext4 a rozdíl byl skoro řádový.

Ja na to reagoval, ze tohle neni normalni chovani a vypada to, ze mu chybel dir_index.
Ty asi budes vazne dementni a nema smysl s tebou ztracet cas.
Jenom prosim nesir dalsi bludy, protoze to tu ctou i zacatecnici a budou zmateni.

[Peter Golis]

Spomínaš pôvodnú otázku, nie vlákno o Roundcube s presunom z XFS na iný FS.

[Bohyně Gaia]

Uz si vzpominam, proc mam Golise mezi zablokovanymi. Mele kraviny.

+1

[pavele]

Ext4 sice byl prohlášený za stabilní před 10 lety, ale není to tak dávno, co měl velké problémy třeba na KVM.

Dnes bych už volil ext4, ext3 nebo ext2 nebo Raiser taky není špatná volba.

Nevolil bych xfs, které se mi zdálo celkově pomalejší - ale má zase jiné features vhodné pro Sambu.

Stejně je nejlepší si vše otestovat a optimalizovat pro konkrétní použití.

[debian+]

v ext4 som mal 2 miliony priecninkov v zlozke. Co sa tyka citania/zapis/exist_file_in_subdir(), je to rychle. Pomalsie bolo uz vypis - list_dir trval 2 s a sort trval 6 sekund ... nebol som len nadseny, ze ked mazalo zlozky po jednom, tak ci tam bola 2 miliony alebo 2 000, vzdy zmazalo len cca 100 za s (odchylka 100%).

[x14]

jen dodávám, že priečinok = zložka

[Peter Golis]

Len dodávam, že zložka = adresár

[jan.rok]

Zkusil jsem si cvičně vygenerovat asi 100 tisíc malých mailů a webový klient s tím problém nemá. Asi bude potíž opravdu v Outlooku.

[youtuber]

a priecninko?

[debian+]

preklep - spravne priecinkov

[youtuber]

Máš smysl pro ironii, chvalím.

[lertimir]

No 100 souborů za sekundu asi odpovídá. Musíš smazat "alokační strukturu" tedy informaci které obsazené sektory disku se operací uvolnily, a záznam v adresáři. Když jedeš journal FS, což ext4 je, tak nejdříve se operace zapíše do žurnálu a pak se teprve provede. A normální 7200rpm disk se otočí 120 za sekundu takže s nějakou pravděpodobností rozložení sektorů se dostaneš na nějakých 200-300 IOPS max. A 2-3 IOPS potřebuješ na smazání.

[debian+]

Zurnal som nevypol (to mi vtedy nenapadlo).

[Pavel 'TIGER' Růžička]

Já osobně jsem věrný extX a i když občas došlo na nějaké selhání (většinou hardware), tak díky zálohám na dalších discích jsem nikdy nepřišel o žádná data. Dnes mám všechny produkční stroje na ext4 a na nic si nestěžuji.

[Michal Kubeček]

Velký počet položek v adresáři byl problém v dobách, kdy ext2 neměl podporu indexovaných adresářů, takže každý adresář byl interně organizovaný jako lineární seznam a operace jako vyhledání nebo smazání položky byly při velkém počtu souborů v adresáři pomalé. Už ext3 podporoval indexované adresáře hned od začátku a to není zrovna horká novinka.

100000 souborů v adresáři není pro žádný z dnešních běžně používaných filesystémů (ext4, XFS, btrfs) žádný problém. Zrovna včera jsem pro potřeby jiné zdejší diskuse zkoušel 10 milionů souborů (tj. stokrát víc) na XFS a ten to zvládal naprosto hladce.

Asi bych se vyhnul JFS (kdysi můj oblíbený) a ReiserFS. Ne proto, že by měly problémy s větším počtem souborů v adresáři, ale jsou méně používané a věnuje se jim podstatně méně vývojářů než ext4, XFS nebo btrfs.

[alkoholik]

Už ext3 podporoval indexované adresáře hned od začátku a to není zrovna horká novinka.

Dovolil bych si nesouhlasit. Ext3 je z roku 2001 a dir_index dostal az o rok pozdeji.

[Michal Kubeček]

Aha, tak díky za opravu. V každém případě mezitím uběhlo dalších 16 let, takže už to stejně bude jedno. :-)

[alkoholik]

Ne tak docela. Jestli nekdo pred 16 lety upgradoval servery jenom zmenou ext2->ext3 ve fstabu, muze mit klidne filesystem bez dir_indexu dodnes. Musi byt lahudka tohle hledat.

[Michal Kubeček]

To by ale byl problém i při konverzi na ext4, který dir_index určitě podporoval hned od začátku. I tam by bylo potřeba dir_index zapnout (a pokud možno i překonvertovat existující adresáře).

Spíš jsem měl na mysli, že možnost, že by někdo měl jádro s podporou ext3, ale bez podpory dir_index, je už spíš jen hypotetická.

[vencour]

Pátrám po detailech ... e2fsprogs řeší věci okolo extX. Když hledám "e2fsprogs dir_index", tak 4. odkaz je na Migrating a live system from ext3 to ext4 filesystem a v něm je i

The "-D" parameter will actually enable the "dir_index" option by rebuilding directory index. It can be rebuilt (optimized) at any later time by running the check with the parameter.

Takže stačí vědět, kdy se tohle objevilo u ext3. A stejně tak by to mohli admini na svejch strojích přebouchat, kdyby opravdu chtěli dir_index a nemaj ho.
U verze 0.3b z února 2000 dir_index podle všeho není.

[alkoholik]

To vime z odkazu uvedeneho vyse: please use e2fsprogs 1.30-WIP-0930 from sourceforge

[alkoholik]

Jednou jsem narazil na problem, kdy jsem v Debianu vytvoril ext3 s default volbami a nebyl jsem schopny ho kvuli nepodporovane feature primountovat ve SLESu (nebo to bylo naopak?). Ale tehdy neslo o dir_index.
Kam se to hrabe na Windows, ktera pri mountu NTFS partition ji automaticky upgradoval na posledni verzi, takze starsi Windows ji uz nezvladly. Dalo se to resit jenom zkopirovanim ntfs.dll z novejsich do starych.

[lertimir]

No to odpovídá tomu, když pan ředitel si upgradoval Word a pak nikdo z podřízených od něj nic nepřečetl, protože měli starší verze. Super pro generování příjmu MS, protože musela upgradovat celá firma.

[Uio]

Pochybuju, ze stačí jen zkopírovat, bez úprav v registru.

[alkoholik]

Sorry, ne .dll, ale .sys.
Vazne to fungovalo.