Vlastní SSD caching pro klasické FS

[RDa]

Mam rozpracovan napad na blokovou SSD cache, tak bych se podelil o myslenky v zajmu o feedback.

Nekteri z nas pouzivaj radeji klasicke filesystemy (ext4), at uz kvuli opravitelnosti, znamemu chovani nebo z jineho duvodu, ale kdyz se me nasbirali desitky TB dat, tak je to ponekud pomalejsi - all-SSD reseni jeste porad neprichazi do uvahy, takze zustava cesta vylepseni vykonu skrze pouziti SSD - jako cache.

Cteci cesta - v SSD se drzi sparse file hlavniho HDD uloziste (na blokove urovni) - s tim ze kdyz je to hit, tak to vraci data rychle ze SSD. Urceni toho, co se ma cachovat trocha pripomina princip jako u prvnich SSD, ktere snoopovali prenaseny obsah - a kdyz se jednalo o casto zapisovanou fat-ku tak delali wear levelling. Ja tady pocitam s tim, ze ta mezivrstva dekoduje strukturu FS do urcite miry, takze vi ktere bloky patri k inode tables a bitmapam, a pak taky muzu jit dal - zapinovat do SSD rovnou i soubory adresaru, nebo malych souboru, pripadne urciteho podadresare (hot pracovni data), nebo v pripade potreby i casti vetsich souboru - napr. meta+thumbnaily z DNG/cDNG nebo metadata/audiotrack z muxovanych video souboru.

Zapisova cesta by mohla jit pres klasicky ssd journal, s opozdenym vyprazdnovanim, coz je spis separatni tema/projekt (resp. tohle by melo bcache zvladat obstojne).

Prvni realizaci planuji skrze userspace - takze se nabizi sitove blokove protokoly (NBD, iSCSI), do kterych muzu vlozit svuj man-in-the-middle processing. Hledal jsem userspace block device, ale je to jen zamaskovane NBD - userspace server. Uzivatelske rizeni pinovani by byla CLI utilita, komunikujici s tim cachovacim jadrem, snooping by bezel zatim vyhradne pro dekodovani EXT4, s tim ze nektere souborove udalosti by zadnimi vratky dostaval skrze iNotify. Pozdeji implementace muze presunout to jadro do kernelu, at odpadne zbytecne kopirovani (bavime se o vyssich stovkach MB/s - co by dal klasicke hdd raid pole). Jeste by se to dalo vylepsit presunem me cache pod LVM a MD vrstvu, takze zapinovany by zustal i cely stripe, ktery obsahuje castecne menici se data, takze by to snizilo rezii pro read-modify-write.

Mam za to, ze nic takoveho neexistuje, a konkurencni LVM cache, bcache, EnhanceIO neumi presne to, co ja chci - resi spis genericky cachovani, ale aplikacne specificky, napr. pro obsah, kterym disponuje programator ci video-editor se to nehodi.

Co si o tom myslite? Kdo ma zajem naprogramovat neco podobneho? At uz jako skolni praci, nebo placene?

[Reklama]

[Miroslav Šilhavý]

V tom nápadu vidím vnitřní rozpor - nebo jsem to možná špatně pochopil.

Pokud vycházíme z premisy, že spousta lidí preferuje tradiční filesystémy (důvody jste vyjmenoval), pak by taková cache musela fungovat zcela autonomně a transparentně z pohledu uživatele a admina (vyjma prvotního nastavení a nějakému občasnému poladění). Jenže v pojetí, které jste následně popsal, by taková cache potřebovala spoustu parametrů, aby byla účinná ke konkrétnímu účelu. Tedy takové oscilování mezi cíly "nevím o tom" a "mám to vyladěné".

Režim "nevím o tom" by si pak IMO moc nezadal s existujícími generickými cache (vyjmenoval jste), a režim "mám to vyladěné" by z toho dělal to samé, co umí např. ZFS.

Jestli je hlavní myšlenkou třeba to, že by to bylo o něco víc, než generická cache (protože by to rozumnělo filesystému, se kterým to pracuje), pak bych do toho, aspoň z počátku, nemotal ty specifické požadavky pro aplikace.

[RDa]

Jestli je hlavní myšlenkou třeba to, že by to bylo o něco víc, než generická cache (protože by to rozumnělo filesystému, se kterým to pracuje), pak bych do toho, aspoň z počátku, nemotal ty specifické požadavky pro aplikace.

Ano, hlavni myslenka je, ze to rozumi datum - a zde neni rozdil mezi strukturou FS, adresari nebo obsahem vevnitr souboru. Ty genericke cachovaci algoritmy nic takoveho neznaj - a cachuji jen "nahodna" data, nejcasteji podle frekvence uziti. Takze az budete strihat nahodne video, cache vam otravi velky soubor ze vcerejska, a pak bude trvat tydny nez se to zaplni potrebnymi informacemi.

Snaha je zvysit celkovou/obecnou rychlost uloziste - bez nutnosti profilovat uzivatelske chovani, takze se zameruji na odstraneni zbytecneho "HDD seek"-u, tj. nutnosti nacitat lookup data pred vlastnimi daty (at uz to je inode table nebo adresare). Tj. cachovat VSECHNY tyto informace.

Princip, ze se udela predavani metadat v ramci hierarchie VFS v kernelu (tzv. "barveni dat") by neumoznil to rozsirit na cachovani casti souboru.

Goal: napoprve udelat find . nebo ls -r bez nutnosti pristupu na HDD, zcela jen ze SSD cache (vyjma prvotni inicializace teto chache, pri jeji aktivaci)

[RDa]

Pokud vycházíme z premisy, že spousta lidí preferuje tradiční filesystémy (důvody jste vyjmenoval), pak by taková cache musela fungovat zcela autonomně a transparentně z pohledu uživatele a admina (vyjma prvotního nastavení a nějakému občasnému poladění). Jenže v pojetí, které jste následně popsal, by taková cache potřebovala spoustu parametrů, aby byla účinná ke konkrétnímu účelu. Tedy takové oscilování mezi cíly "nevím o tom" a "mám to vyladěné".

Tady to berte jako opak TRIM-u, namisto uvolneni prostoru, by se prostor oznacoval za dulezity - at uz pro casti souboru nebo pak cele podadresare, takze by se tato oblast zapinovala do cache. Tohle neumi zadny existujici cachovaci system.

Samozrejme k tomuto je potreba uzivatelska intervence - jak ve volbe toho co chcete zapichnout, nebo toho, jakym typum souborum to ma rozumet - jiste je jiny pristup u programatora, ktery voli "cache all *.c", a jiny u fotografa, ktery chce rychle thumbnaily z raw-u.

(u BTRFS taky nastavujete COW a noCOW na adresare.. tady si nastavite cache co a kde, a kde nikoliv)

[branchman]

Nedokaze bcache v principe to iste?
Zober si to tak - ked k hlavickam alebo thumbnailom DNG pristupujes castejsie ako k zbytku suboru, tak v cachi zostane co chces. Cele to vyzaduje ovela menej logiky a teda tam bude menej bugov. Parsovanie lubovolnych suborov v kerneli si pyta velku nestabilitu, ved kolko zranitelnosti existuje v existujucich programoch, kde sa programatori vo formatoch vyznaju.
Ked pristupujes vzdy k celemu suboru, tak nema vyznam robit cache hlaviciek.

[Reklama]

[RDa]

Nedokaze bcache v principe to iste?
Zober si to tak - ked k hlavickam alebo thumbnailom DNG pristupujes castejsie ako k zbytku suboru, tak v cachi zostane co chces. Cele to vyzaduje ovela menej logiky a teda tam bude menej bugov. Parsovanie lubovolnych suborov v kerneli si pyta velku nestabilitu, ved kolko zranitelnosti existuje v existujucich programoch, kde sa programatori vo formatoch vyznaju.
Ked pristupujes vzdy k celemu suboru, tak nema vyznam robit cache hlaviciek.

bcache to nedokaze udelat predem (resp. nevim o tom jak tomu expliticne ridit seznam bloku) - jenom profiluje uzivatele. To bys musel v cron-u poustet skript, ktery by cetl ty hot data, a takova neprima metoda predavani informaci o tom, co chces cachovat, je to, co nechci a  resim - aby se jasne reklo - TOHLE chci. Samozrejme se nebranim tomu, ze to bude cachovat vic nez je treba, ale resim to minimum, co v cache MUSI byt.

Nechci to parsovani resit v kernelu, proto ten pristup pres inotify helper. Do jadra cache se jen predaji cisla bloku, ktere se maji vzdy cachovat, a v pripade nutnosti vyssiho vykonu / nizsi spotreby se tohle jadro muze presunout do kernelu.

bcache muze resit tu zapisovou cache, pro kterou bylo primarne vyvinuto - ze na SSD se ukladaj vsechny zmeny, ktere se pomalu odsypaj na disk, to jo, tam to smysl ma. Ja resim nutnost cteni cehokoliv - a okamzite z cache - zadne profilovani chovani uzivatele. Snooping obsahu je neco jineho a to bcache neumi.

[_Tomáš_]

jaký máš use case pro takovouhle věc? Nestačí ti něco jako vmtouch (https://hoytech.com/vmtouch/)?

Na serverech s dvěma desítkami plotnových disků a miliony souborů na každém s tímhle nemáme tak velké problémy, spoustu věcí odchytne raid řadič a kernel cache, vysoký paralelismus to řeší a stejně saturujeme disky. Větší problém je malá page size v linuxu, která nedovoluje dostatečně těžit z iops více disků nebo z nvme.

Jak tady někteří říkali, ext4 se používá pro jednoduchost, přímočarost a stabilitu, dodělávat tam takovéhle věci můžeš velice rychle se rozloužit se stabilitu. Jak třeba budeš řešit konzistenci, při loadu načteš vše do ssh cache? Co hotswap?

[RDa]

jaký máš use case pro takovouhle věc? Nestačí ti něco jako vmtouch (https://hoytech.com/vmtouch/)?

Jak tady někteří říkali, ext4 se používá pro jednoduchost, přímočarost a stabilitu, dodělávat tam takovéhle věci můžeš velice rychle se rozloužit se stabilitu. Jak třeba budeš řešit konzistenci, při loadu načteš vše do ssh cache? Co hotswap?

To neresi zrychleni nahodneho pristupu od nepredikovatelneho uzivatele, ktery prochazi sve uloziste. Vlastne to prochazeni se snazim zrychlit - at uz proto, ze se na to diva clovek netrpelivy, nebo proto, ze chci zkopirovat milion souboru. Bohuzel pri poslednim kopirovani 40TB dat jsem zjistil, jak je to naprd, kdyz hlavicky litaj sem a tam.. protoze pristupujete k datum, ktere nebyly profilovany.

Konzistence lze resit tim, ze se cache invaliduje, pokud je superblock mount time jinej nez cachi-znamej. Pak staci natahnout data podle sparse bitmapy znova - vi se co se ma cachovat, jen si nejsme jisti obsahem. Proto to taky resim jako RO path cache a nechci do toho motat zapisy.

[Miroslav Šilhavý]

To neresi zrychleni nahodneho pristupu od nepredikovatelneho uzivatele, ktery prochazi sve uloziste. Vlastne to prochazeni se snazim zrychlit - at uz proto, ze se na to diva clovek netrpelivy, nebo proto, ze chci zkopirovat milion souboru. Bohuzel pri poslednim kopirovani 40TB dat jsem zjistil, jak je to naprd, kdyz hlavicky litaj sem a tam.. protoze pristupujete k datum, ktere nebyly profilovany.

Toto stojí za rozebrání, abychom věděl, že hovoříme o tom samém.
Načtení velkého adresáře trvá dlouho, ale ne vždy za to může filesystem.

1. Je potřeba zkusit ls s parametry, které ho nezdrží. Např. barevný výpis dělá stat na každém souboru. Spoustu času zabere i třídění - takže je potřeba dostat data nejprve unsorted. Je mi jasné, že toto neposune vpřed onoho "nepredikovatelného" uživatele, ale je potřeba vědět, jaký problém ve skutečnosti řešíte.
2. Zkoušel jste na ext4 vobu dir_index?

[czechsys]

Zajimalo by mne, jak mate nacenen vyvoj/administraci takoveho reseni oproti full-ssd poli.

[mhi]

Pres userspace to bude pekelne pomale, reseni typu ze se udela nejaky iscsi target ktery to bude "nejak resit" je myslim spatna cesta.

Kdysi jsem programoval kmodule na pripojovani NTFS stripe-setu, byl to jednoduchy modul ktery otevrel vice block devices a spojoval je vhodne do jednoho, fungovalo to docela dobre a minimalni overhead. Cestu bych videl treba v tom urcit ze struktury filesystemu ktere bloky se budou cachovat a ty mit na SSD (tzn. na zacatku HDD bude mapa toho co je odlite na SSD, nebo jen vubec na SSD).

Proc SSD, proc to necachovat v SDRAM ? Odber? Cena?

[RDa]

To neresi zrychleni nahodneho pristupu od nepredikovatelneho uzivatele, ktery prochazi sve uloziste. Vlastne to prochazeni se snazim zrychlit - at uz proto, ze se na to diva clovek netrpelivy, nebo proto, ze chci zkopirovat milion souboru. Bohuzel pri poslednim kopirovani 40TB dat jsem zjistil, jak je to naprd, kdyz hlavicky litaj sem a tam.. protoze pristupujete k datum, ktere nebyly profilovany.

Toto stojí za rozebrání, abychom věděl, že hovoříme o tom samém.
Načtení velkého adresáře trvá dlouho, ale ne vždy za to může filesystem.

1. Je potřeba zkusit ls s parametry, které ho nezdrží. Např. barevný výpis dělá stat na každém souboru. Spoustu času zabere i třídění - takže je potřeba dostat data nejprve unsorted. Je mi jasné, že toto neposune vpřed onoho "nepredikovatelného" uživatele, ale je potřeba vědět, jaký problém ve skutečnosti řešíte.
2. Zkoušel jste na ext4 vobu dir_index?

Chci eliminovat vsechny seeky rotacnich disku, do doby, nez se bude pristupovat k opravdovym datum souboru.
Pro pristup k adresari potrebujete 2 seeky pro kazdou uroven pod-adresaru (cteni directory entry a cteni inode tabulky).

Vypnuti barvicek, trideni, nebo treba locate index, neni to, jak si predstavuji zrychleni prace s FS - spis naopak, chci dosahnout stavu, ze i s temi barvickama a fstat na kazdy souboru, se to provede stejne rychle, jako kdybych pracoval se SSD. fstat nepristupuje k datum souboru, ale jen k inode table, a ano - nez se to natahne, tak to udela zcela zbytecne hromadu seeku.

Resim tedy problem zbytecnych seeku pro lookup metadat. Ackoliv EXT je neco jako distribuovana FAT-ka, takze nemusi sahat vzdy az na kraj disku, tak je tam porad hromada kmitani - v pripade rekurzivniho cteni se delaj 3 seeky pro kazdej soubor, v pripade SSD cache/overlay pro metadata, lze mit pristup na soubor skrze 1 primy seek.

Prakticky tedy tak, aby to byl "sparse mirror" (deravej RAID-1) mezi SSD a HDD, s preferencnim ctenim SSD, kdy to SSD pozadovana data obsahuje (podle bitmapy nebo stromu), s moznosti uzivatelskeho rizeni (editaci bitmapy), co se ma/nema drzet v SSD.

Konkretni ukazka na hdd poli s 29.75M inodama, kdy by na disk nebylo vubec potreba sahnout - vse potrebne by totiz melo byt v te SSD cache:

Kód: [Vybrat]

df -i
IUsed: 29750446

/mnt/files # date; find /mnt/files/ -type d | wc -l; date
Wed Dec 16 10:46:24 AM CET 2020
2664789
Wed Dec 16 12:19:02 PM CET 2020
To nam dela 92m38s = 5558 sec runtime, a fstat s rychlosti 5353 inode/sec.

Pouzita cast inode table dela 3.8 GB (z 62GB moznych) + pro kazdy adresar mame minimalne 4K blok na direntries. Celkove se muselo nacist v nahodnem poradi minimalne 930K inode a  2664K dent bloku. Prenosy na poli jsem videl kolem 1 az 4 MB/s - protoze je to omezeno seekovanim, pocitaje tyto 4K bloky, tak to dela 646 iops/sec (je to R6, 8+2 disky).

slabtop kdyby nekoho zajimalo:

Kód: [Vybrat]

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
3022776 3022770  99%    1.00K 755694        4   3022776K ext4_inode_cache
2499420 2491156  99%    0.19K 119020       21    476080K dentry
3100266 2966827  95%    0.10K  79494       39    317976K buffer_head
322091 322072  99%    0.56K  46013        7    184052K radix_tree_node
 32914  32914 100%    3.27K  16457        2    131656K raid6-md3
600796 600778  99%    0.14K  21457       28     85828K ext4_groupinfo_4k
468864 352110  75%    0.04K   4736       99     18944K ext4_extent_status
 13286  12690  95%    0.55K   1898        7      7592K inode_cache

Spusteni prikazu samozrejme zacne cist disk znova, protoze v ext4_inode_cache nejsou podrzeny vsechny.. (nemam to ted potunene, pac predesla zkusenost byla, ze dochazela pamet).

Nektere tyto SLAB-y jdou nastavit aby se udrzeli v pameti dele ci vetsi, ale neresi to nahodny pristup po zapnuti - inicializaci nelze provest jinak, nez normalnim ctenim struktury a tudiz nahodnymi pristupy na disk coz trva. A neresi to vubec moznost cachovatelnosti konkretne oznacenych souborovych dat.

Pro srovnani, na ext4 SSD s 1.17M inodama:

Kód: [Vybrat]

# date ; find . -type d | wc -l ; date
Wed Dec 16 12:04:12 PM CET 2020
71649
Wed Dec 16 12:04:34 PM CET 2020
zde tedy fstat jede s rychlosti 53393 inode/sec

Aplikacne specificke pouziti:

Mate treba cDNG videa - 100K souboru v adresari pro kazdej klip, kdyz zanedbame overhead pro samotny adresar, tak v pripade spusteni prehravani (v editoru/barvicim sw), zacne disk kmitat mezi inode table, pripadnou indirect tabulkou a daty souboru. V pripade cachovani vsech urovni pristupovych metadat v SSD, by disk cetl jen video framy.

A ne-posledni ucel: kvuli hromade souboru, ktere se pak povaluji po celem disku, bych rad nektere data sbalil do vnoreneho FS (at uz iso/udf, nebo ext4 image) - treba proto, abych celou vec mohl rychleji - tj. linearnim ctenim - presnutou jinam. A tohle se tim userspace demonem da taky rozparsovat - a pro tyto vnorene FS image nechat nacachovat jejich pristupove udaje.

[RDa]

Pres userspace to bude pekelne pomale, reseni typu ze se udela nejaky iscsi target ktery to bude "nejak resit" je myslim spatna cesta.

Na dnesnim hw to tak marny neni - treba ddrescue jede blocksize defaultne 512B - na rychlem poli to cetlo podivne kolem 500MB/s, coz je limit dany user/kernel kontext switchem a kopirovanim dat - cca 1M switchu na mem hw. Pri zvyseni block size neni problem dosahovat 2GB/s, ale to uz to omezovali disky. Nez jsem na to prisel, ze to ma takovy block size by default chvili trvalo :-)

Ale nebranim se, aby to rozhodovaci jadro bylo v kernelu, jen to neni jednoduchy na pocatecni vyvoj.

Proc SSD, proc to necachovat v SDRAM ? Odber? Cena?

Zas tolik pameti nemam / nechci obetovat.

V RAM bude lookup strom/bitmapa s referencema na to, co je kam odcachovane, to jo, ale samotne datove bloky radeji tedy perzistentne v SSD. Jak predpokladam cachovani zajimavych casti souboru, tak se nebavime jen o pristupovych strukturach, ale i o nekterych datech, takze se nekolik set GB v ssd/nvme typu Optane se na tohle hodi zcela idealne.

Zajimalo by mne, jak mate nacenen vyvoj/administraci takoveho reseni oproti full-ssd poli.

Pokud se prokaze ze treba ty Optane disky se hodi prave na tohle.. nemel by byt problem najit sponzora k vyvoji.

Provozne to neni tak kriticky prvek, jak napr. bcache, bez ktereho nejste schopni namountovat disk, protoze obsahuje modifikace nad ramec toho nizsiho uloziste. Ja resim hlavne zrychleni cteni, tim, ze informovane vim ktere bloky za to stoji drzet v cache.

[Miroslav Šilhavý]

Já se obávám, že to, co popisujete, by mělo ve výsledku takovou komplexitu, jako ty filesystémy, které jste v premise zavrhl. Protože když začnete ošetřovat stavy, které mohou nastat, a řešit, co nastane i v budoucnosti, vznikne z toho šílený moloch, který ani neaspiruje na to, aby se s takovými problémy vypořádal koncepčně. Můžeme začít jen s některými situacemi:

- na SSD se zapíše, ale na rotační ne (důvody: výpadek napájení, poškození HDD)
- na SSD se data poškodí, ale na rotačním jsou v pořádku (důvody: poškození SSD, např. vadný firmware)
- někdo externě (offline) změní data na HDD
- změna parametrů či samotné struktury filesystému (viz např. přechody ext2=>ext3=>ext4)
- správné plánování kapacity SSD (velikost struktur není dopředu dána) => co dělat, když začne docházet, jakým algoritmem vyberete, co zahodíte
- která data bude ještě OS cachovat v RAM? jak to bude efektivní (z hlediska rychlosti i konzumace prostředků)

Určitě dojdete k dalším a dalším dilematům, která budete řešit "podle svého" (tj. spousta dalších s tím bude nespokojená).

Myslím, že poznámka o finanční efektivitě je taky na místě. SSD dnes stojí houby a tam, kde je potřeba rychlost operací, tam jsou (musejí být) i peníze. Nevidím moc velký problém mít živá (pracovní) data na SSD a méně často užívaná na rotačních discích. Ten finanční rozdíl není tak závratný, aby se vyplatilo to opravdu systémově řešit. Nepochybuji, že se najde dost lidí, kteří by to brali - pokud to někdo udělá a oni budou jen konzumovat. Jakmile ale každý začne přemýšlet o hodnotě svého času, přijde mu proti tomu SSD komicky levné a tím to skončí.  Spoustu use cases řeší výše zmíněné cache a taky složitější filesystémy. Takže cílovka je sakra moc úzká. Taky nezapomínejte, že cena SSD klesá a bude klesat dál, takže než dojdete do rozumného bodu ve vývoji, tak už bude zase menší důvod to používat.

Ale abych nebyl jen negativní, zmínil jste něco jako "děravý raid-1 s prioritou". Když už se do něčeho takového pouštět, pak by mi přišlo, že toto je cesta k rychlému cíli. Mapa, která v prvním kroku určí, které bloky jsou zrcadlené a určí blok na úložišti (SSD bude menší než HDD, takže se to musí namapovat). Najde blok v mapě? Pak v případě čtení brát ze SSD, v případě zápisu zapisovat do SSD a zpožděně na HDD. Fajn, to by jít mělo. Jak velká taková mapa bude a jak rychle se v ní bude hledat? Kolik RAM a cyklů to sežere? Bude to po blocích, nebo po nějakých větších či dynamicky určených jednotkách a na bloky se to převede až v konečné fázi? Myslím, že od této úvahy byste mohl začít, protože to se dá spočítat na papíře dřív, než začnete.

[RDa]

Ale abych nebyl jen negativní, zmínil jste něco jako "děravý raid-1 s prioritou". Když už se do něčeho takového pouštět, pak by mi přišlo, že toto je cesta k rychlému cíli. Mapa, která v prvním kroku určí, které bloky jsou zrcadlené a určí blok na úložišti (SSD bude menší než HDD, takže se to musí namapovat). Najde blok v mapě? Pak v případě čtení brát ze SSD, v případě zápisu zapisovat do SSD a zpožděně na HDD. Fajn, to by jít mělo. Jak velká taková mapa bude a jak rychle se v ní bude hledat? Kolik RAM a cyklů to sežere? Bude to po blocích, nebo po nějakých větších či dynamicky určených jednotkách a na bloky se to převede až v konečné fázi? Myslím, že od této úvahy byste mohl začít, protože to se dá spočítat na papíře dřív, než začnete.

Ale tohle je prave to jadro meho pudla!
(a zbytek chytrosti je jenom runtime uprava "tvaru sita" / bitmapy)

Urychli to veskere lookupy na uroven vykonu SSD, vyhledani v nespojite mape nevidim jako kriticky bod.

Myslim ze vetsinovy use-case genrickeho uloziste je read-intensive pouziti, ti co potrebuji tocit TB objemy v read/write rezimu maji davno SSD-only reseni. Pro bezneho uzivatele, ktery data vytvari jednou a pak jenom pouziva, nedava reseni zalozene ciste na SSD smysl.

Vyber EXT4 (nebo jinych EXT) je vyhoda - struktura je dobre zdokumentovana, a inode tabulky jsou vzdy na stejnych lokacich. To se da oznacit rovnou podle hlavicek fileystemu. Druha uroven dat jsou dir_entry, soubory s obsahem adresare. Ty jsou jiz nahodne rozhazene po disku, stejne jako neprime indexy pro tabulky bloku (ext3) nebo extents (ext4). Tim ze jsem ext4 reader jiz jednou implementoval podle popisu struktur, v tom nevidim buhvijaky problem.

Ohledne mapy: pokud se vezme naivne mapovani 16TB na 16TB prostoru (4G x 4K bloky), tak to mate linearni tabulku citajici 16GB (4G x 32bit), s lookupem trvajici jedno nahodne cteni RAM adresy. Ale tim, ze ten SSD overlay bude hodne sparse, tak lze tuhle vyhledavaci mapu pojmout v podobe "pagetables" - hierarchie, nebo jine stromove / hashovane struktury, resp. indexovane extents seznamy, optimalni na vyhledani 32bit polozky (16T ssd) na zaklade cca 40bit+ indexu (4 PB hdd). Na tohle si myslim existuje jiz slusne overena implementace (ostatne SSD to dela take, s mnohem mensimi zdroji, nez mate k dipozici na PC).

Pokud bych chtel byt linej, tak to rovnou muzu udelat jako sparse soubor na tom SSD a nechat sparsovanost resit skrze hotovy filesystem, ale nevim jak moc na tom je podpora zatazena do userspace, abych dokazal urcit zda je blok alokovan, ci nikoliv.