Administrace komentářů

Btrfs se hodí pro virtuální obrazy disků, protože se pak dají obrazy klonovat okamžitě pomocí cp --reflink, tedy bez fyzického kopírování velkých objemů dat. V situacích, kde klonování obrazů není potřeba, samozřejmě tato výhoda ztrácí význam. Místo omezování CoW u jednotlivých souborů a adresářů se dá vytvořit subvolume a ten pak přimountovat s optionem nodatacow. Otázka ovšem je, proč to dělat. Na SSD to s největší pravděpodobností úplně postrádá smysl a je lepší vždy používat CoW. Na běžném disku rovněž není úplně jisté, že se Btrfs s CoW nehodí na virtuální obrazy disků. Nechal bych to koňovi, přesněji řečeno optionu autodefrag, a případný problém s fragmentací kvůli CoW bych řešil teprve tehdy, pokud by opravdu nějaký nastal.

Nevím, že by „se“ PostgreSQL nedoporučoval pro databázové soubory. Filesystém s copy-on-write by byl přímo ideální pro databáze, kdyby ho ovšem databáze explicitně podporovaly (tedy kdyby používaly aspoň obdobu cp --reflink, když už ne něco sofistikovanějšího na úrovni bloků). Některé sady benchmarků porovnávají (mimo jiné) výkon pgBench na Btrfs a jinde zase někdo zkoušel vyhodnotit vliv Btrfs (včetně komprese) na výkon PostgreSQL. WiKi od ArchLinuxu stále ještě tvrdí, že se má PostgreSQL spouštět jen s nodatacow, ale nepřikládal bych těmto „moudrům“ zásadní váhu. Měl jsem PostgreSQL na Btrfs s copy-on-write, kde zaprvé natrhlo prdel hračce zvané MySQL (až dvojnásobně rychlé zpracování některých joinů nad půlterabytovou databází). (Dlužno ovšem dodat, že byly všechny dotazy drtivě CPU-bound, protože PostgreSQL ani MySQL nemají (zatím) vícevláknové vyhodnocování dotazů.) Každopádně jsem nezaznamenal ani náznak nějaké „nevhodnosti“ Btrfs pro databáze.