Dotaz: Arch - přechod na BTRFS

[Honza]

Plánuji přejít (novou instalací Arche) na BTRFS a mám na zkušené tři dotazy:

- instalace bude na SSD podporující TRIM. Je rozumnější používat manuálně (případně automatizovat cronem) fstrim nebo dát rovnou do fstab možnost discard? - jak je to s příznakem autodefrag? používá se pro BTRFS také? - co se složkou obsahující virtuály? Budu mít BTRFS pod LVM (kvůli swap oddílu), takže můžu vytvořit další ext4 oddíl pro virtuály. Raději bych ale měl složku s virtuály pod BTRFS. Někde jsem ale četl, že příznak NODATACOW na subvolume nefunguje. Bude tedy stačit na prázdnou složku aplikovat chattr +C?

Předem děkuji za reakce.

Odpovědi

[Andrej]

Já používám všude discard (skrz Btrfs, LUKS i LVM), ale zdá se, že to může být víc škody než užitku. Těžko říct. Asi to teda mám všechno špatně.

autodefrag mám všude zapnutý, i na SSD, ve stylu „because we can“. Je na nekonečnou debatu, jestli to dává smysl. Výkon by to zlepšovalo jedině při nějaké extrémní fragmentaci, která je nepravděpodobná. Opotřebení SSD to asi zvyšuje, ale jedině pokud je nějaká defragmentace skutečně potřebná a provádí se. Beru to tedy tak, že v případě hypotetické extrémní fragmentace by to (trochu) pomohlo s výkonem, za cenu opotřebení SSD — ale SSD je prostě k tomu, aby se používalo, takže co má být —, a v jakémkoliv jiném (běžném) případě to nedělá skoro nic.

Ano, chattr +C je pořád asi jediná možnost, jak lokálně aplikovat nodatacow. Disky s virtuály bych rozhodně dal do odděleného subvolume, aby se dalo v budoucnu plynule přejít na ten mount option, až jednou (snad) bude per-subvolume.

[Honza]

Dík, víceméně to potvrzuje moje doměnky. Discard je opravdu otázka a v rúzných fórech nebo wiki jsou mnohdy opačné názory. Autodefrag někdo vyloženě na SSD nedoporučuje, ale zase názory a zkušenosti nejsou jednotné. Jinak doplňující dotaz: jelikož plánuju na disk šifrování tak se obávám, že fstrim používat nepůjde? Virtuály tedy dám do odděleného volume a na příslušnou složku použiju chattr +C ještě před tím, než do ní překopíruju soubory.

[Andrej]

Mám za to, že fstrim používá seznam volných bloků v souborovém systému a ten bude fungovat vždy, zcela bez ohledu na to, zda je příslušné zařízení šifrované či nikoliv.

Problém je ale v tom, že discard i fstrim můžou (teoreticky) u šifrovaného zařízení vést k úniku jistých dat (například o rozmístění různých bloků se známým obsahem) a tím k oslabení zabezpečení, které šifrování poskytuje. Pár odkazů je tady. Záleží také na zvoleném typu šifry.

[Honza]

A je tedy potřeba dávat v Archi příslušný záznam (allow-discards) do /etc/crypttab, aby uměl na šifrovaném oddílu discard / fstrim?

[Andrej]

Já ho tam vždycky dávám. I kdybych nakonec při mountu filesystému discard nepovolil, není od věci mít discard uschopněný na všech ostatních vrstvách jako LUKS, LVM, GPT, kdovícoještě až po hardware. Pak se celá věc ovládá na jednom místě (mount option nebo spuštění fstrim) a není třeba myslet na těch několik dalších vrstev (a hledat v dmesg, kde se to zadrhlo).

[Honza]

Díky, rozumím. Takže discard uschopním nejen na LUKS, ale i na LVM.

[Honza]

Přeci jen ještě doplňující dotaz: když budu mít discard uschopněný pro root v mkinitcpio a vše ostatní budou BTRFS suboddíly, tak bych vlastně discard pro LUKS v /etc/crypttab nemusel (neměl) řešit?

Skoro si pohrávám s myšlenkou nechat kus neformátovaného místa na SSD a discard vůbec neřešit. Obzvlášť kvůli šifrování....

[Andrej]

…tak bych vlastně discard pro LUKS v /etc/crypttab nemusel (neměl) řešit?

Měl, protože /etc/crypttab se (pokud se nepletu) zkopíruje z /etc do toho initcpio obrazu / souborového systému, aby se v initramdiskové fázi bootu dal ten šifrovaný kontejner otevřít rovnou správným způsobem. A právě tam už musí to nastavení být, má-li se uplatnit.

Pokud jde o souborový systém uvnitř toho LUKS kontejneru, já dávám povolení discardu i do kernelových optionů, ale v tomhle jdu špatným příkladem ;-P, protože je to zbytečná blbost — v implicitním nastavení se totiž root (/) namountuje napřed read-only, takže discard nedává žádnž smysl, a pak se později přemountuje read/write, už podle /etc/fstab, kde bude discard povolený. Protože se provádí remount na read/write, discard se prostě bez problémů zapne.

U toho LUKS kontejneru/oddílu se ovšem žádná obdoba remountu nedělá — jakmile je na něm root (/), bude už otevřený stejným způsobem po celou dobu uptime systému. Proto by měl mít nastavení už od úplného začátku.

Ve Fedoře existují kernelové optiony, které si přečte Dracut a které umožňují zapnout discard v LVM, LUKS i Btrfs nezávisle na další konfiguraci systému. Už si nevzpomínám, jak přesně je to v Archu a/nebo na vanilla kernelech. Ale /etc/crypttab rozhodně v Archu funguje ve spojení s mkinitcpio přesně podle očekávání, tj. zkopíruje se do toho úvodního ramdisku (dokonce s hláškou během vytváření toho initcpio obrazu) a použije se pak při bootu velmi brzy, přesně jak je potřeba.

Samozřejmě taky musí mít /etc/mkinitcpio.conf v sobě správné hooky. Já mám například na jednom systému nešifrovaný /boot, protože GRUB kdysi dávno neuměl LUKS a neuměl tedy bootovat z šifrovaného oddílu (ach jo), takže mám GPT tabulku oddílů, na ní je EFI boot oddíl a druhý oddíl s LVM, v tom LVM je /boot (nešifrovaný) a všechno ostatní je LUKS oddíl, v LUKSu je další vrstva LVM a v něm malý swap a Btrfs (vše ostatní). Je to stejné jako konfigurace popsaná tady. Hooky v Archu pak musí být něco jako … lvm2 encrypt lvm2 resume …, aby se všechny vrstvy otevřely. (To například na Fedoře není potřeba, protože tam Dracut sám rekurzivně hledá a otevírá vrstvy abstrakce tak dlouho, dokud nenajde oddíl s požadovaným UUID, který poslouží jako root.)

Dnes už bych tohle^^^ asi nedoporučoval, protože GRUB umí LUKS, takže je možné mít jen jednu vrstvu LVM. Tedy mít GPT, na tom EFI + LUKS oddíly a v LUKS oddíle buď rovnou Btrfs, nebo LVM a na tom jeden swap LV a jeden Btrfs LV.

[Honza]

Tak znovu díky za vyčerpávající reakci.

Musím se na to znovu podívat, ale Arch píše že root mít v /etc/crypttab nechce a nechává to na initcpio. Jinak ano, na Archi musejí být hooky v /etc/mkinitcpio nastaveny, tj. ...keyboard encrypt lvm2 resume filesystem ....

Já budu instalovat na MBR, takže plánuji LUKS na celý disk, v tom jednu vrstvu LVM a v ní potom jeden swap LV a jeden Btrfs LV se subvolumes. Boot na rootu.

[Love_Dali]

Osobně používám ArchBang jako základ a nechávám AB aby sám nastavil fstab. Takže mám:

[petr@Archbang Diablo II]$ cat /etc/fstab 

UUID=1e1286cc-4640-46fc-8fd4-918b61f129cd       /               btrfs           rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0

# /dev/sda6
UUID=b53aef57-cee8-472e-a8c9-d20b482c7198       /home           btrfs           rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0

[petr@Archbang Diablo II]$ 

Nějak jsem se v tom nehrabal a swap už tak 3 roky vyplý (core i5 2450m @2.5GHz, 6GB RAM) a problém jsem nenašel. SSD je OCZ Vertex 4 a už to bude hezkých pár let, co jej mám :).

Právě jedu na plasmě 5.7.x a ani GnomeShell nebo cokoliv jiného si nestěžovalo.

Cheers

[Honza]

Díky. Koukám, že discard ve fstab nemáte. Používáte tedy fstrim?

[Trubicoid2]

discard tam mám, navíc jednou denně v cronu fstrim -a

Navíc mám compress=lzo a noatime, autodefrag nemám. I když říkají, že to stejně dělá, třeba se to časem změní.

ssd nemám, to stejně sám detekuje

[Love_Dali]

Hmm, pravda. Používal jsem vždycky. Nahodím :)

[Love_Dali]

I když (a možná mě opravte) netrimují už novější SSD samy?

[Honza]

Viz. diskuze vyse....