Který filesystém na Linuxu pro adresář s velkým množsvím malých souborů?

Prosím o nápovědu, který filesystém na Linuxu je aktuálně nejvýhodnější pro adresář s velkým množstvím (10.000 nebo více) malých textových souborů (většina o velikosti desítek kB, malá část větších souborů do velikosti jednotek MB).

Obsah jednotlivých souborů se nebude měnit, prostě každý jednotlivý soubor bude zapsán a časem případně smazán, ale po zapsání souboru na disk se jeho obsah už nebude měnit.

Vzhledem k textovému obsahu souborů by se mi hodila transparentní komprese.

Na linuxu je nejmodernejsi file system btrfs
Souborový systém Btrfs
Kompresy umi

Zamyslet se nad filozofii dat - hodne souboru v jednom adresari je vzdy chyba navrhu aplikace

btrfs bych určite nedoporučoval člověku, který se na tohle musí ptát. 10t ještě není tolik, v zásadě na podobné vylomeniny vždy ten nejjednodušší, ale v tomhle množství poslouží ext3/4 dobře.

Kompresí malých souborů moc neušetříš.

Jak píše vdusek, není takovéhle řešení vhodné. Osobně na podobné věci používám sqlite, pokud nejsou jiné požadavky.

1) Na správu serveru mám lidi, ale potřeboval jsem si ujasnit paramentry pro návrh aplikace

Vím, že transparentní kompresi umí NTFS, ZFS a btrfs. Nebo ji umějí i nějaké další filesystémy? (Squashfs nepočítám, ten je read-only)

Domnívám se, že ext3 ani ext4

Ale nevím, do jaké míry jsou použitelné na Linuxu nějaké linuxové implementace NTFS a ZFS a do jaké míry umějí transparentní kompresi i na Linuxu (pokud si vzpomínám, ZFS se používá buď přes FUSE, což se mi moc nelíbí, nebo se může použít ZoL, ale ten možná není úplně stabilní; implementací NTFS existovalo vícero a nevím, zda je nějaká z nich dost zralá na produkční nasazení)


2) Proč "kompresí malých souborů neušetřím"? Například se tak mohu z velké části zbavit problémů s alokací -- pokud se mi malý soubor zkomprimuje do velikosti nejmenší alokační jednotky ve filesystému, nemůže fragmentovat, i kdyby chtěl.


3) Použít Sqlite (nebo rovnou MySQL nebo PostgreSQL) je logická úvaha, ale nejsem si jist, jak by se popasovala s těmi soubory -- mohou se v nich objevit i "divné" znaky (nejen ASCII + interpunkce + diakritika) a některé mohou mít i velikost jednotek megabajtů (přestože většina má desítky kB). Takže bych asi potřeboval datový typ LARGEBLOB v MySQL a nějaký obdobný v PostgreSQL, ale trochu mě děsí tohle:
https://wiki.postgresql.org/wiki/Bin..._in_a_database.
No a mít takhle velké bloby v Sqlite je už hodně velký punk.

Co se treba podivat, jak to dela treba squid cache - cilene si vybuduje adresarovou strukturu a tu vyuziva pro ukladani malych souboru

Nejaka deduplikace/on-line komprese v dnesni dobe uz ztraci v beznem provozu na vyznamu

Z hlediska filesystemu je nejlepsi se drzet overenych standardu, usetri to mnoho problemu pri prusvihu

ZFS umí deduplikaci, ale při takhle malém množství souborů nemusí dobře fungovat. Komprimovat jednotlivé soubory zvlášť nebývá tolik efektivní, máš změřeno kolik tím ušetříš místa? Mluvíš o desítkách tisíc malých souborů, to jsou desítky až stovky MB dat, to je opravdu takový problém s velikostí?

Nevymýšlej nestandardní řešení, to je vždy těžká cesta. NTFS bych nedoporučil, btrfs není pro začátečníky a musíš s ním mít dobré zkušenosti, fuse není vhodný obecně pro důležitá data, ZoL je stabilní a uvažuje se u FreeBSD o jeho použití místo jejich implementace.

Sqlite je binary safe, je mu šomák co tam má uloženo, stejně tak ostatní db, které umí bloby. Sqlite je zlatý grál mezi malými databázemi, čistě a stabilně napsaný kód, ověřena v produkci po dekády a nasazena ve všech možných malých zařízení (např. využívá jí masivně android), pár zdrojů máš v oficiální dokumentaci https://www.sqlite.org/fasterthanfs.html, https://www.sqlite.org/sqlar.html. V ČR jsem to používal na desítkách projektů (nikoliv malých systémů, používá to interně cisco, juniper, mellanox, redhat), velice těží z journalů na ext4.

Pro obrovské množství souborů je vhodnější FS, které nepotřebuje jeden obrovský index pro celý svět, jako fat. EXT3/4 není vůbec špatný a tohle zvládne v pohodě, raiser samozřejmě bude na miliony souborů efektivnější. Největší problém jsou nástroje v rámci glibc (standardní mv, cp, find atd.), které pracují jednovláknově, takže celou složku musí procházet i na silném serverů v jednom threadu a to je prostě pomalé. Když něco podobného dělám, bucketuji soubory do složek po cca 10 tis souborech, tím tyhle nástroje výrazněji zefektivním. Vždy je lepší volba použít stabilní a ověřený FS a lehce mu přizpůsobit aplikaci než zkoušet nestabilní a neověřené implementace na podobné nasazení (fuse s ntfs).

Velké webové servery a CDH, které pohánějí velkou část českého internetu běží nad ext3, celkově obsahují desítky miliard souborů v několika FS a desítkách tisíc složkách, hranice jsou poměrně daleko, ale již to znamená určitou míru správy a znalostí.

Postresql má dokumentaci zde https://wiki.postgresql.org/wiki/BinaryFilesInDB, zkušenosti mám s miliony souborů do jednoho MB (PDF) a funguje to plynule a podle očekávání, fragmentace FS je malá, odezvy a reakce očekávané a stabilní.

Původně odeslal vdusek ↪

Co se treba podivat, jak to dela treba squid cache - cilene si vybuduje adresarovou strukturu a tu vyuziva pro ukladani malych souboru

O to se právě snažím a přemýšlím, jak to nadimenzovat, proto se ptám

Původně odeslal vdusek ↪

Nejaka deduplikace/on-line komprese v dnesni dobe uz ztraci v beznem provozu na vyznamu

Komprese a dekomprese probíhá relativně rychle v RAM, zatímco seekování na disku a čtení dat je pomalé; no a SSD má zase omezený počet zápisů => nechci jej rychle zhuntovat

Původně odeslal vdusek ↪

Z hlediska filesystemu je nejlepsi se drzet overenych standardu, usetri to mnoho problemu pri prusvihu

Proto se obávám jít např. do NTFS na Linuxu, přeci jen je to nepříliš vyzkoušená kombinace

NTFS na linuxu je nouzovka - hodne veci vyresi velikost RAM/cachovani

NTFS na Linuxu jako hlavni filesystem neni vhodny pristup.

soubory jsou uloženy v blocích na FS, můžeš zvolit jejich velikost takovou, aby soubor byl přes co nejméně bloků. Určitě na takové soubory vol samostatný oddíl než máš OS, abys jeho parametry mohl měnit nezávisle. Jedná-li se o malé soubory, komprese ti opravdu tolik nepomůže (chce to ale přesná čísla a měření). Enterprise SSD jsem ještě neviděl rozbité a to je používáme několik let na plně zatížené databáze. Samozřejmě raid 1 na diskové oddíly a zálohování je samozřejmost.

RAM fs cache je v tomhle případě důležitá, nech většinu paměti nevyužité, aby kernel mohl paměť využívat.

Forma ukládání do databáze se často volí právě kvůli zálohování a zachování konzistence s metadata. Na několika projektech jsem pro ukládání souborů volil couchdb/couchbase, ač plýtvá místem, mohl jsem replikovat miliony souborů opět nebyl žádný problém.

I v tvém případě se jedná o desítky tisíc souborů (jak sám píšeš), zbytečně bych to nekomplikoval. Nech si udělat na tyhle soubory vlastní oddíl na disku, řekni správcům/adminům, že tam budeš mít velké množství malých souborů, aby správně nastavili FS. Aplikaci napiš tak, aby soubory dělila do složek. Časté řešení je soubory ukládat s názve jako nějaký hash (obsahu či cokoliv unikátního k souboru) a prvních několik znaků použít pro název složek, tím zajistíš poměrně solidní rozložení bez více práce.

Jinak na setreni mista nevyuzitych bloku v pripade malych souboru se pouziva reiserfs, ale ten od dob kdy autor ma statem narizenou pauzu asi stoji na miste.

Jak již bylo řečeno, na tohle je perfektní sqlite.
Počtěte si o nějakých benchmarcích zde: https://www.sqlite.org/fasterthanfs.html

Sám používám sqlite jako uložiště pro fotky a pdf soubory.
Momentálně databáze servíruje přes 300 000 souborů a odezva je parádní. Zálohování a přenositelnost takové databáze je také velmi praktická, protože se vlastně jedná o jeden kompaktní soubor.