abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 01:00 | Zajímavý projekt

Collapse OS vznikl jako svobodný operační systém pro počítače v případě „pomalého kolapsu civilizace“ sestavitelné a udržovatelné ze součástek rozšířených zařízení jako kalkulátory Texas Instruments, a to za účelem programování dalších jednočipů pro automatizaci. Autor po roce a půl projekt označil za hotový, ale plánuje pokračovat v jeho vylepšování. Ke stažení jsou zdrojové kódy (pod GNU GPLv3) a dokumentace.

Fluttershy, yay! | Komentářů: 0
včera 14:33 | Komunita

Nvidia podpoří projekt Common Voice částkou 1,5 milionu dolarů. Mozilla píše o demokratizaci a diverzifikaci hlasové technologie. Nvidia prostě použije otevřenou databázi hlasových záznamů k trénování svého systému Jarvis, viz úvodní přednáška CEO Nvidie Jensena Huanga na NVIDIA GTC 2021.

Ladislav Hagara | Komentářů: 0
včera 09:00 | IT novinky

Tento týden probíhá virtuální konference NVIDIA GTC 2021 (GPU Technology Conference). Doporučit ke zhlédnutí lze úvodní přednášku CEO Nvidie Jensena Huanga. Z kuchyně představil celou řadu novinek (NVIDIA Grace CPU, NVIDIA DRIVE Atlan, AI-Capable Supercomputer Alps, …). Dění na konferenci lze sledovat na Twitteru.

Ladislav Hagara | Komentářů: 3
včera 08:00 | Nová verze

Byla vydána verze 6.0 softwaru pro správu vlastního cloudu OpenNebula (Wikipedie). Kódový název nové verze je Mutara. Přehled novinek v poznámkách k vydání v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
včera 00:55 | Komunita

Vedení Nadace pro svobodný software (FSF) vydalo oficiální prohlášení k návratu Richarda Stallmana (RMS) do vedení FSF. Richard Stallman promluvil ke komunitě kolem svobodného softwaru.

Ladislav Hagara | Komentářů: 23
12.4. 20:33 | Pozvánky

Ve středu 14. dubna pořádá brněnský Red Hat tradiční akci Open House, letos opět ve virtuální podobě. Open House nabízí studentům, ale i zájemcům z široké veřejnosti příležitost poznat Red Hat, jeho kulturu a dozvědět se o stážích a pracovních příležitostech. Letošní program nabídne 3 souběžné streamy od více než 30 přednášejících. Jeden z nich bude věnován technickým přednáškám, kde se dozvíte o různých projektech a produktech, na kterých

… více »
Dorka | Komentářů: 0
12.4. 16:11 | IT novinky

Microsoft kupuje firmu Nuance Communications za 19,7 miliardy dolarů. Nuance Communications se věnuje rozpoznávání řeči pomocí umělé inteligence především ve zdravotnictví. Technologie od Nuance Communications je použita také ve virtuálním asistentovi Siri.

Ladislav Hagara | Komentářů: 12
12.4. 14:44 | Nová verze

Český překladatelský tým LibreOffice vydává příručku LibreOffice Writer verze 6.4. Kniha představuje některé hlavní funkce aplikace LibreOffice Writer:… více »

Zdeněk Crhonek | Komentářů: 0
12.4. 13:33 | Nová verze

Příspěvek na blogu webové aplikace pro spolupráci na zdrojových kódech pomocí gitu Gitea (Wikipedie) představuje novinky nové verze 1.14.0 této v programovacím jazyce Go naprogramované aplikace.

Ladislav Hagara | Komentářů: 0
12.4. 09:00 | Nová verze

V březnu 2016 byl 2D animační software Toonz uvolněn jako open source pod názvem OpenToonz. O víkendu byl OpenToonz vydán ve verzi 1.5.0. Přehled novinek v poznámkách k vydání na GitHubu. Novou verzi bude možné nainstalovat také z Flathubu a Snapcraftu.

Ladislav Hagara | Komentářů: 0
Kolik času v průměru denně trávíte videohovory/-konferencemi? (ať už v práci, škole nebo soukromě)
 (52%)
 (13%)
 (15%)
 (10%)
 (7%)
 (1%)
 (1%)
Celkem 293 hlasů
 Komentářů: 7, poslední 8.4. 12:14
Rozcestník

Dotaz: DM-cache (nejasnosti)

4.4. 10:13 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
DM-cache (nejasnosti)
Přečteno: 779×
Má někdo zkušenost s nastavením thresholdu dm-cache ve smyslu, že se tato nebude vyhýbat cachování sekvenčních IO operací? Idea je před RAID5(mdadm) pole (4x8TB) předřadit 2TB NVMe dm-cache ve snaze zajistit rychlejší náhodný/sekvenční přístup k naposledy uloženým/využívaným datům (cca 1-2TB záběrů)?

Je správný předpoklad, že po nahrání dat na origin device zkrze dm-cache bude vlastně předcachováno ve prospěch následných čtecích operací (těchto dat)?

Netuším nakolik ZFS (ARC/L2ARC/SLOG/ZIL/..) jsou funkční alternativou bez výrazně vyšších HW nároků. Cílem je v ideálním případě dosáhnout při čtení průchodnosti v řádu GB/s (na cachovaných datech).

Odpovědi

Max avatar 4.4. 15:17 Max | skóre: 69 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Nemám s tím zkušenosti, ale podle dokumentace si myslím, že tebou zamýšlené funkcionality docílit nejde. Kromě toho, že sekvenční operace se nekešují, tak i dost těžko ovlivníš, co v té keši chceš mít. Samozřejmě můžeš zkusit nastavit nějakou monstrózní velikost u "sequential_threshold", aby se kešovaly i sekvenční operace a "read_promote_adjustment" nastavit na něco malého, aby se ti kešovalo skoro všechno, co budeš číst, ale jestli to bude mít nějaký výkonnostní bonus, to těžko říci :-/. Navíc na to SSD pak budeš i ve velkým zapisovat i jen při samotném čtení, což nebude asi také moc ok.
Dále tím, že zapisuješ, děláš write keš, nikoli read keš. Takže samotným zápisem dat si read keš nevytvoříš. Read keš si vytvoříš opakovaným čtením stejných dat.

Nemůžeš si udělat workflow dat v rámci userspace? Něco v tom smyslu, že když budu s něčím potřebovat operovat, tak si to nejdříve nahraju na to NVMe, tak si s tím budu hrát a pak to hodím zpět na to pole?

Pokud jde o ZFS, tak tam pro kešování slouží L2ARC, ale opět, jedná se o kešování dat, která často používáš. Tj. podobný případ jako výše. Ale také nemám reálné zkušenosti, nepoužívám L2ARC, jen SLOG (= write cache).
Zdar Max
Měl jsem sen ... :(
4.4. 17:21 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
aby se kešovaly i sekvenční operace a "read_promote_adjustment" nastavit na něco malého, aby se ti kešovalo skoro všechno, co budeš číst, ale jestli to bude mít nějaký výkonnostní bonus, to těžko říci
Já měl za to, že metadata-device udržuje seznam bloků uložených v cache-device, tj. jak těch načtených při čtení tak těch určených k zápisu na origin-device(dirty blocks). Proč by se muselo znova cachovat čtením z origin-device, když úspěšně propsaný dirty block obsahuje shodná data (jako origin-device).
Navíc na to SSD pak budeš i ve velkým zapisovat i jen při samotném čtení, což nebude asi také moc ok.
Pokud se budou číst stejná data (scrubbing po timeline), mělo by to na základě existence daných bloků v metadata-device snad pouze přečíst odpovídající bloky z cache-device?
ale jestli to bude mít nějaký výkonnostní bonus, to těžko říci
Pokud diskové operace v rámci aktivního projektu probíhají na 1TB+ dat z obsahu filesystému mělo by cache-device 2TB být schopno obsahovat prakticky vše k čemu se přistupuje? Prakticky "FIFO", pokud by vše mělo stejnou váhu.
Nemůžeš si udělat workflow dat v rámci userspace?
Ano to mám jako náhradní řešení. Aktivní data leží v /NVMe/xyz a je na ně vytvořen symbolický link z /mount_raid5/xyz, který se využívá v rámci projektu (kromě toho leží stejná data ještě v /mount_raid5/xyz.hdd jako redundance). Po ukončení zpracování se link zrusi a přejmenuje xyz.hdd na xyz, cimz je v budoucnu zajisteno zachovani schodne cesty jako te pouzite v rámci referenci na klipy v projektu.

Bude to chtit praktický pokus. ;-)
Max avatar 4.4. 18:48 Max | skóre: 69 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Rozlišuje se keš pro zápis a keš pro čtení. Aby se ti něco dostalo do keše pro čtení, musíš to nejdříve přečíst. Tím, že něco zapisuješ nedostaneš data do keše pro čtení.

Nejspíše je tedy pak průběh následující :
1) pošleš zapsat soubor "test.txt"
2) dostane se do write cache (seznam dirty blocks určený pro zápis), tedy pokud bude zápis odpovídat definovaným politikám
3) na pozadí se data dozapíší na origin device
4) až budou data úspěšně zapsána, v keši nic nebude (metadada-device a metadata-cache by měly být prázdná)
5) přečteš jednou soubor "test.txt" z origin device
6) pokud budeš mít "read_promote_adjustment" nastaven na velkou hodnotu, tak se soubor do keše nemusí dostat
7) v keši vydrží tak dlouho, dokud ho z ní nevytlačí nějaká jiná data, což se stane až se začne keš plnit na max

Hodnoty se definují v rámci IO, aspoň tak je to ve zdrojákách:
read_promote_adjustment:    READ io, default 4
write_promote_adjustment:   WRITE io, default 8
discard_promote_adjustment: READ/WRITE io to a discarded block, default 1
Takže nezajistíš, aby se zapisovaný soubor udržel v cache hned automaticky pro čtení. Aspoň tak mi to dle dokumentace vychází. Každopádně asi si zkusím ve volné chvíli udělat nějaký test, docela mě to zajímá, jak se to reálně umí chovat.
A nebo se tu k tomu vyjádření opravdu někdo, kdo to blíže zkoumal a testoval.
Zdar Max
Měl jsem sen ... :(
4.4. 20:06 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Díky za detailní rozbor.

Vyhradil jsem na pokusy 500GB SATA III SSD (to by v sekvenčních rychlosti čtení mělo cca odpovídat RAID5 ze čtyř 7200rpm disků) a 1TB NVMe Samsung 970 Pro (MLC 2-bit).
metadata/cache-device

dev/nvme0n1:
 Timing buffered disk reads: 9414 MB in  3.00 seconds = 3137.43 MB/sec

origin-device
/dev/sdf:
 Timing buffered disk reads: 1526 MB in  3.00 seconds = 508.19 MB/sec

4.4. 21:16 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Pouzit LVM postup
Zápis prakticky rychlostí SSD (WD500 Blue)
time dd if=/dev/zero of=/raid5/bigshit2  bs=1M count=32768 
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 117,671 s, 292 MB/s

real	1m57,677s
user	0m0,020s
sys	0m23,641s

Prvni cteni (cache na NVMe se dle iostat  plni)
time cat /raid5/bigshit2  >/dev/null 

real	2m8,042s
user	0m0,110s
sys	0m12,518s

prvni cteni nacachovanych dat 32GB file
time cat /raid5/bigshit2  >/dev/null 

real	0m33,120s
user	0m0,050s
sys	0m9,654s

druhe cteni nacachovanych dat 32GB file
time cat /raid5/bigshit2  >/dev/null 

real	0m14,718s
user	0m0,037s
sys	0m6,437s

(base) root@xub184:~# time cat /raid5/bigshit2  >/dev/null 
real	0m28,535s
user	0m0,046s
sys	0m8,966s
(base) root@xub184:~# time cat /raid5/bigshit2  >/dev/null 

real	0m14,718s
user	0m0,037s
sys	0m6,437s
(base) root@xub184:~# time cat /raid5/bigshit2  >/dev/null 

real	0m11,885s
user	0m0,029s
sys	0m6,244s
(base) root@xub184:~# time cat /raid5/bigshit2  >/dev/null 

real	0m13,743s
user	0m0,045s
sys	0m6,997s

dle iostat cteni z NVMe(cache device) spickove presahuje 2GB/s

Pozn. RAM je 32GB, takze by se tam 32GB soubor nemel soubor vejit (zkusim radeji soubor 96GB).

4.4. 22:05 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
test na 96GB file
zapis na origin storage (limit SATA SSD)
time dd if=/dev/zero of=/raid5/bigshit3 bs=1M count=98304
98304+0 records in
98304+0 records out
103079215104 bytes (103 GB, 96 GiB) copied, 375,234 s, 275 MB/s

real	6m15,255s
user	0m0,041s
sys	1m13,642s

prvni cteni (plneni cache)
time cat /raid5/bigshit3  >/dev/null 

real	6m14,875s
user	0m0,310s
sys	0m35,797s

prvni cteni s vyuzitim cache prumerne >1,5GB/s
time cat /raid5/bigshit3  >/dev/null 

real	0m58,806s
user	0m0,113s
sys	0m27,762s

druhe cteni s vyuzitim cache
time cat /raid5/bigshit3  >/dev/null 

real	0m51,978s
user	0m0,107s
sys	0m26,724s
Vypada to, ze dochazi k aktualizaci metadat (zapisy na NVMe pri cteni), asi pro statistiky cetnosti vyuzivani dat (idealni by bylo kdyby toto slo vypnout, donutit to aby to nedavalo prednost zadnym datum).

Potvrdilo se, ze zapsane informace se nepouziji pro read-cache. Znamenalo by to v ramci naplneni cache je po nakopirovani jednorazove vycist do /dev/null. Pokud se to ovsem nebude chovat jako ciste FIFO (proc jinak ty zapisy pri cteni), neni garance ze se s novym projektem nova data dostanou do cache (statistiky vyuzivani dosavadnich dat by mohly prevazit?). V pripade takoveho chovani by se cache by se asi nejspis musela znovu reincializovat, aby se umoznilo naplneni novym obsahem.

Pri praci s timeline nemusi byt cten cely soubor (scrubbing jde po datově vzajemne vzdalenych snimcich). Bez prednaplneni cache by se stridaly rychle dostupne (jiz nacachovane snimky) a ty pomale (ktere jeste nebyly nacteny/obsazeny v cache).

Vypada to, ze to funguje, ale pro dany ucel mam obavu ze to bude z hlediska cache-hit ratio asi nevypocitatelne. Dana uloha je asi prilis vzdalena cilum tohoto reseni.
Max avatar 5.4. 16:35 Max | skóre: 69 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Díky za info, takže se to chová dle předpokladu.
Jinak pokud jde o ten větší zápis při dalších čtení, může to být tím, že při prvním čtení není celý soubor v read cache ;-). Ostatně to by pak i vysvětlovalo, proč další čtení (v příkladu třetí) jsou o kapánek rychlejší, než to první z cache (v příkladu to druhé čtení).
Zdar Max
Měl jsem sen ... :(
5.4. 17:43 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Jestli to používá LRU tak to pravděpodobně musí občas aktualizovat metadata (pouze v RAM si to asi neudrží). Chtělo by to samostatný device pro metadata, pak by to bylo ještě zřejmější.
5.4. 21:00 j
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Rek bych, ze ten tvuj test je dost postavenej na vode.

1) neco zapisujes => laduje se to do cache (nejen na SSD, ale i pripadne do RAM). 1,5) .... ta cache se v ocekavani dalsich zapisu prubezne vyprazdnuje 2) zacnes neco cist, ale z cache to uz bylo vyhozeno.

Tvuj problem spociva v tom bode 1,5, coz IMO muzes pomerne razantne ovlivnit (= jak rychle se ti misto v cache bude vyprazdnovat).

A mimochodem 292 MB/s by odpovidalo tomu, ze se zadna cache pri zapisu nepouzije, coz je i standardni nastaveni pri linearnim zapisu (da se to zmenit). I Satovy SSD by prelezlo 500MB/s. Takze jak chces zjistovat, jestli v ni neco je, kdyz si do ni nic neulozil?

---

Dete s tim guuglem dopice!
5.4. 21:22 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Bavíme se stále o fungování dm-cache?

Ty hodnoty v testech odpovídaly průběžným hodnotám z iostatu (jak při plnění obsahu na SSD-origin-device .. sustain write cca 250MB/s jde o levné TLC SSD, zápis do NVMe cache-device při prvním čtení dat z origin-device, tak následné čtení cca 2GB/s+ z NVME cache-device při opakovaných čteních z origin device.
Max avatar 6.4. 00:17 Max | skóre: 69 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Podle mě "j" nepochopil, jak dm-cache funguje a o čem je tu řeč, jinak si tu jeho poznámku nedokážu vysvětlit.
Zdar Max
Měl jsem sen ... :(
6.4. 01:06 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Taky jsem získal ten dojem.

Teď se vyprodávají malé M.2 Optane 32GB, ten by jako metadata device mohl být vlastnostmi zajímavý. Je to dnes asi mrtvá technologie, ale za zkoušku stojí. ;-)
6.4. 18:34 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
32GB M.2 Optane dorazil

Jak zmiňuje specifikace rychlost sekvenčního čtení je okolo 1350MB/s (zápis asi 290MB/s).
sudo hdparm -t  /dev/nvme1n1
/dev/nvme1n1:
 Timing buffered disk reads: 4008 MB in  3.00 seconds = 1335.94 MB/sec
Výdrž má být 182,5TBW, což při velikosti 32GB znamená cca 5840 úplných přepisů.

Velikost struktur metadata-device se údajně stanovuje výpočtem 4M + (16 * velikost_cache_device / velikost bloku), což by při 1TB cache-device a 256KB bloku představovalo asi 65MB (0,2% kapacity Optane).

Zařízení disponuje dvěma PCIe 3.0 linkami, což ukazuje i lspci.
41:00.0 Non-Volatile memory controller: Intel Corporation Device 2522 (prog-if 02 [NVM Express])
	Subsystem: Intel Corporation Device 3806
...
		LnkCap:	Port #0, Speed 8GT/s, Width x2, ASPM not supported, Exit Latency L0s unlimited, L1 unlimited
			ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 8GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
		LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
...
	Kernel driver in use: nvme
6.4. 20:14 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Stejný pokus jako včera, pouze cache-meta umístěna na M.2 Optane.

Plnění origin-device daty, u cache=device a meta-device drobné zápisy (asi čtení struktur FS). Včerejší pokus byl patrně zpočátku ovlivněn LAZY mkfs.ext4. Dnes jsem nechal přípravu FS odeznít. ;-)
time dd if=/dev/zero of=/raid5/bigshit3 bs=1M count=98304
98304+0 records in
98304+0 records out
103079215104 bytes (103 GB, 96 GiB) copied, 377,044 s, 273 MB/s

real	6m17,111s
user	0m0,046s
sys	1m12,945s
První čtení souboru z origin-device a plnění cache-device
time cat /raid5/bigshit3  >/dev/null

real	6m8,772s
user	0m0,280s
sys	0m36,910s
 
Druhé čtení souboru z origin-device (vypada to, že při prvním čtení se nenacacheovala všechna data, čte se i z origin) .. průměrná rychlost 96GB/83s cca 1GB/s+
time cat /raid5/bigshit3  >/dev/null

real	1m23,199s
user	0m0,123s
sys	0m29,300s
Třetí čtení souboru z origin device
 time cat /raid5/bigshit3  >/dev/null

real	1m18,568s
user	0m0,140s
sys	0m30,340s
Čtvrté čtení (podíl nacachovaných dat se zvětšuje)
time cat /raid5/bigshit3  >/dev/null

real	1m6,874s
user	0m0,148s
sys	0m30,356s
Páté čtení
time cat /raid5/bigshit3  >/dev/null

real	0m53,109s
user	0m0,114s
sys	0m30,113s
Šesté čtení
time cat /raid5/bigshit3  >/dev/null

real	0m46,084s
user	0m0,120s
sys	0m29,251s
Sedmé čtení
time cat /raid5/bigshit3  >/dev/null

real	0m42,074s
user	0m0,124s
sys	0m29,348s
Sedmé čtení
time cat /raid5/bigshit3  >/dev/null

real	0m40,288s
user	0m0,104s
sys	0m29,255s

Osmé čtení (z originu se čtou v průměru pouze jednotky MB/s)
time cat /raid5/bigshit3  >/dev/null

real	0m38,916s
user	0m0,123s
sys	0m29,540s

Deváté čtení (z originu se během celého čtení 96GB načetlo odhadem asi 10MB) .. 96GB/40s = 2,4GB/s
time cat /raid5/bigshit3  >/dev/null

real	0m38,644s
user	0m0,130s
sys	0m29,469s
Algoritmus pro cachování má svou hlavu. ;-)

Perlička na závěr, mountpoint /raid5 nebyl nejšťastnějším. Právě mi do něj vlezl TimeShift a pokouší se bigshit3 zálohovat. :-)
Max avatar 7.4. 08:32 Max | skóre: 69 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Cache slouží k urychlení přístupu k datům, tj. nelze očekávat, že tam budeš mít celý soubor 1:1, což ale nijak nevadí.
Zdar Max
Měl jsem sen ... :(
7.4. 09:52 Aleš Kapica | skóre: 50 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
No. Hlavně by asi mělo zaznít, že hlavním cílem je urychlit práci se soubory. Rotačním diskům vyhovuje sekvenční zápis, takže ta keš by měla podle nějakých parametrů shromáždit blok dat k zápisu a ten následně zapsat.

Systém předá data DM-cache, ta mu potvrdí příjem a tím považuje I/O operaci za dokončenou. Bez DM-cache by musel čekat, až příjem potvrdí všechny disky RAIDu.

Jestli to funguje i pro čtené nevím. Blbnul jsem s tím už hodně dávno. Každopádně pokud tam někdo navalí tolik dat, že zaplácne kapacitu toho kešovacího disku, tak to stejně bude čekat, než se to zapíše na ty disky rotační.

A taky je na místě upozornit, že se tímto způsobem ten NVME disk extrémně rychle opotřebovává, pokud je těch I/O operací moc a ve velkých objemech.
7.4. 11:44 PetebLazar | skóre: 26 | blog: l_eonardovo_odhodlani
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
O urychlení zápisu v tomto use case nejde, takže se vystačí s defaultní write-thru policy (nepozoroval jsem zapisy do cache-device při nahrávání dat na origin-device).

Cílem je umožnit maximálně procachovat na poli umístěnou podmnožinu velkých souborů (B-RAW) využívaných v rámci aktivního projektu (NLE). Tyto soubory dosahují bitrate v řádu stovek MB/s. S ohledem na pokles sekvenční rychlosti HDD s úbytkem počtu sektorů směrem ke středu zajištění vyšších rychlostí ~1GB/s vede k polím s větším počtem členů (latence typické). V případě umístění zájmových souborů v NVMe cache je možné docilit zajímavých rychlostí čtení (včetně latencí) i při HW slabším poli. Amortizace NVMe zápisem by nemusela být problémem, ve zcela ideálním případě se do něj zapíše pouze objem odpovídající souhrnu objemu aktivních projektů. Samozřejmě za předpokladu, že aktivní(zpracovávaná) data v daném okamžiku nepřesáhnou velikost NVMe cache.
Max avatar 7.4. 13:29 Max | skóre: 69 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: DM-cache (nejasnosti)
Má poznámka se vztahovala k read cache, která se tu řeší.
Zdar Max
Měl jsem sen ... :(

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.