Vlákno názorů k článku Souborový systém Btrfs: kontrola dat a pokročilé použití od Filip Jirsák - Jak je to s tou databází, vypnutím COW...

Jak je to s tou databází, vypnutím COW a snapshoty? Rychlé snapshoty samozřejmě závisí na COW – znamená to, že když udělám snapshot, bude btrfs příznak vypnutí COW ignorovat? Nebo mi vůbec nedovolí snapshot na oddílu přimountovaném s vypnutým COW udělat? Nebo (to by byla nejhorší možnost) to btrfs vůbec neřeší a s vypnutým COW bude klidně přepisovat data ve snapshotu?

Já jsem k tomu psal výše, že celé doporučení vypínat CoW na databáze mi přijde pochybné. Jaký existuje lepší případ pro CoW, než u databází? (Výkonnostně to nemůže mít měřitelný vliv, díky zápisu pages.)

Záleží na tom, jak má databáze data uspořádaná. Ale obvykle jsou databázové soubory optimalizované z pohledu rotačních disků, aby se předešlo fragmentaci. Pak samozřejmě vypnutí CoW dává smysl, protože CoW vám to celé rozbije a soubor fragmentuje.

Ano, to je snad jediný případ. U většiny filesystémů stejně nemáte možnost rozumně fragmentaci ovlivnit a nastavovat databázi podle "situace na discích" je zbytečně komplikované. Filesystem (a volume manager) je zde od toho, aby znal topologii disků a určoval, jak je nejlepší zapisovat. Databáze má být od tohoto dilematu odstíněná jak jen to jde. Ve skutečnosti databáze neumějí předejít fragmentaci na discích.

ZFS tento gap řeší pomocí ARC a ZIL (Adaptive Read Cache a ZFS intent log). Pokud je nenastavíte, ano, přicházejí nevýhody. Pokud je nastavíte, přicházejí výhody. Třeba si myslím, že provozovat ZFS (analogicky Btrfs) bez ARC/ZIL je případ bez use case. Nedovedu si moc představit, jaké výhody má okleštěné ZFS (Btrfs) oproti tradičnímu filesystému. Databáze bez CoW, snapshoty, které plně a výkonně nezajistí atomicitu - no pěkně děkuju, to mi přijde naprosto vyhovující Ext4 a jediné, v čem se přizpůsobím je způsob archivace a zálohování.

Ono se vůbec vymýšlejí kombinace bez use cases.

Velky databaze casto nepouzivaj filesystem vubec. Proste zapisujou primo na disk. Zadny nastavovani neni potreba DB server se o vse postara sam a fragmentaci samozrejme resi vlastnimi nastroji.

Snapshot lze pořídit i s nocow. Ke zkopírování změněného bloku dojde, ale jen jednou, při jeho první změně. Takže bez problémů.

Jinak balíčky některých db (vím určitě o PostreSQL v Debianu) nocow na datových adresářích nastavují už roky. Takže je to do značné míry již zavedeno v praxi.

Takže je to do značné míry již zavedeno v praxi.

Otázka je, jestli to není jen nějaký hotfix na stav Btrfs, postupně povýšený na standard.

Odpověděl jsem vám výše. Velmi záleží na konkrétní architektuře dané DB, ale některé dělají něco jako COW sami (už jen z důvodů viditelnosti záznamů různými transakcemi).

To ano, ale CoW má zanedbatelnou režii. Zápis stránky (ať už se jedná o existující nebo novou) trvá stejně s CoW, jako bez něj. Jediný rozdíl je v napojení zapsané stránky - a ta režie je (měla by být) absolutně zanedbatelná. Na flash médiích se stejně nepřepisuje stejný fyzický blok.

Pokud má existovat nějaký význam CoW, tak je právě v tom, že aplikace by měly (postupně, volitelně) přestat řešit starost o zápis dat a přenechat to na filesystému. Vypínání CoW jde naprosto proti velké výhodě Btrfs či ZFS. Jak Filip správně poznamenal, ztratí filesystem možnost inteligentně (s malou režií) řešit snapshoty, takže další ztráta proklamované výhody.

Pokud má něco výkonnostní výhodu, pak je to nastavit správnou velikost stránky na filesystému vs. databáze. Vypínat CoW je špatně.