Vlákno názorů k článku
Linus Torvalds má výhrady ke kódu Bcachefs pro 6.9
od Izak - Mi bi se libilo, kdyby BTRFS umelo SSD...
-
Mi bi se libilo, kdyby BTRFS umelo SSD jen jako read cache, tedy by nevadilo, kdyby se poksodil, nebot primarne by mel data na rotacnim raidu, ale jen casto pouizvane bloky mel na SSD, cimz by se brutalne zrychlila rychlost cteni, cache v RAM by byla vice mene hlavne pro zapis a vyupadek SSD by neposkodil data - mozna uz to ma LVM a ja to jen nesatudoval, nebot pouzivam primarne ent. diskova pole ...
Tam je to prav e ruzne, kdyz jsou full flash tak je jasno, SSD cahce soucasti raidu jsme vetsinou utlokli a kdyz se prezene IO a mnozstvi dat, tak je to zabije do te miry, ze je lepsi je nemit, nebot zpomelni ja nasbne pomalejsi nez kdyz tam SSD vubec neni - idelne kdyz to detekuje a prestane to delat - coz pak delal treba 3par nebo hitachi, kdyz tam prehazoval bloky velmi konservativne a pri pretizeni se na to vykaslal - aby preve nezabil spindle disky persouvanim dat mezi SSD a spindlem.
A pak treba infinidat, kde jsou SSD jen pro RO a tak co uz neni potreba se proste oznaci jako smazane, prazdne bloky, asi kasle na TRIM, ten je pomaly a na zapis ma RAM - ECC a servery/nody na UPS ... NetApp mel ve sve dobe flash cache, coz byla de fakto karta s kupou RAM a bylo to taky jen pro cteni, nebyla tak zalohovana baterkou, na rozdil od RAM - ono uz je dnes temer vse PC s linuxem nebo freebsd - stare karty melky RW cache s baterkou aby posledni zapisy zustaly a po obnove proudu se zapsaly na disky ...
Reseni RO SSD cache je ale velmi dobre reseni, nebot nejcasteji nejvice zpomaluje cetni, nebot tam se ceka na hlavicky, zatimco zapisy se de fakto sypou tam kde zrovna jsou bez ladu a skladu ;-)
U BRTFS je vyhoda, ze by to mohl umet prave FS ... a pokud by to bylo jen pro cteni, tak by byla temer jistat, ze nebude nicit data --- coz by u hot bloku, kde by se vse zapisovalo pres SSD nastat mohlo
-
Na necem podobnem pracuji - sparse mirror. Mas dve sady zarizeni - tj. HDD a SSD, kdezto to SSD je derave - "sparse", a slouzi primarne jako RO cache (rezim s write cache by vlastne znamenal tam mit dirty bitmapu), a pokud umre, nic se nedeje. Pri zapisu je treba samozrejme updatovat i to SSD.
Jak moc ta mensi ssd cache pokryva vetsi hdd pole zavisi na tom, ktere bloky se oznaci jako cachovatelne - primarni FS na hdd poli je EXT4*, takze mam cache bootstrap resen skrze zjisteni, ktere bloky jsou zajimave - vicemene to jsou systemove bloky (inody, bitmapy), adresarove soubory, a pak male soubory, nebo casti velkych souboru ktere obsahuji index (video) nebo nahledy (obrazky).
Sparsovitost bych rad ridil z userspace a mel to spise pod kontrolou, nez to nechat na systemu - tam ma smysl jenom hooknout fs driver, aby oznacoval nove vytvorene adresarove bloky jako cachovatelne. Ono se vlastne nic nestane, kdyz neco bude nebo nebude cachovatelne - rozdil je jenom v rychlosti nebo pak opotrebovavani SSD.
Netapp flash karty mam, to byl vlastne takovy predchudce NVMe :) Ale zajimavejsi jsou bateriove zalohovane RAM disky, taky pripojene skrze pcie - to muze slouzit jako neopotrebovatelny write intent log / zurnal. Ty novejsi co jsem mel, meli nvme api, a zapisy v radech PiB :)
* u EXT4 je disk layout primocary, na rozdil od chytrych FS ktere integruji raid/dedup/cow/snapshoty. Pokud bych mel neco podobneho resit na necem jinem nex EXT4, tak bych spis uz ohnul nfs cache, ktery cachuje na vfs urovni.
-
A ma to zmysel pri dnesnych cenach SSD/NVMe a rychlosti HDD riesit? Ja mam HDD namountovane na na klasicke velke veci ako videa, obrazky, ... archiv, ostatne je na NVMe. System so vsetkym SW sveta ktory potrebujete musite napchat do niekolko 100GiB (ja momentalne so vsetkym bordelom tam mam 193GiB) a tmpfs v RAMke:
tmpfs 1.6G 2.1M 1.6G 1% /run
tmpfs 7.8G 175M 7.6G 3% /dev/shm
tmpfs 5.0M 8.0K 5.0M 1% /run/lock
tmpfs 1.0G 46M 979M 5% /tmp
tmpfs 2.0G 1.2G 832M 60% /var/cacheMne osobne nechyba absolutne nic.
