ZFS root pool elrendezése

Naplózó filerendszerek (journaling)

Szeretnék egy ZFS-t egy Debian alá root filerendszernek. Ezen a poolon nem lesz felhasználói adat (/home, /srv), az másik diszkeken lesz másik poolban más redundanciával. Házi szerver, nem production kategória.

Van egy jó leírás itt: https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS

Ehhez képest szerintem lehetne egyszerűsíteni a 3-as pont környékén, és ebben kérnék tanácsokat, és hogy jó-e a gondolatmenetem. Sokat olvastam már a ZFS-ről, de gyakorlati tapasztalat 0, az majd most jön.

1. A leírás nem az rpool-t csatolja fel /-nek, hanem rpool/ROOT/debian-t. A többi datasetben teljesül a hierarchia, hogy rpool/home->/home, rpool/var->/var, stb., de itt nem. Mi ennek az értelme? Az pool önmagában egy dataset is, tehát simán lehetne rpool->/. Hierarchia ellenére lehet állítgatni minden dataset propertyjeit külön-külön vagy egyben, snapshotolni is lehet külön-külön vagy egyben. Technikai limitációról se tudok, azt kivéve, hogy magát a root pool-t érdemes rpool-nak nevezni, de ez a ROOT/debian furcsa.

2. Csomó datasetre be van állítva a com.sun:auto-snapshot. Ez eléggé Solaris specifikusnak tűnik, ezért kihagynám. És engem marhára nem zavar, ha a rendszer snapshotokba belekerül pl. a /var/cache. Olyan kevés adat lesz ezen a poolon eleve (~10 GB) a teljes diszkhez képest (~240 GB), hogy inkább azt mondom, legyen meg inkább a kelleténél több a snapshotokban, mint hogy azt kockáztassam, hogy valami kimarad és ezért nem tudok visszaállítani valamit.

3. El van aprózva a sok dataset: /var/spool, /var/log, stb. Ez még elég konszolidált, sokan szétszedik /usr-t, /usr/local-t, /boot-ot, stb. Mi hátrányom van abból, ha én nem aprózom el, és extrém esetben csak egy dataset lesz az egész rootfs alatt? Szerintem nem sok. (És meg tudom gondolni magam később, init 1+rsync kombóval.)

4. UTF-8 normalizáció is be van állítva a leírás szerint. Pontosan tudom, hogy ez mit csinálna. De találkozott már valaki olyan esettel, ahol erre tényleg volt szükség? utf8only-t szívesen állítok. Nem hiszem, hogy lenne olyan eset, hogy egy é betű kétféleképpen van kódolva ugyanabban a mappában. Tudtommal a kliensek (Linux ext4 és Windows NTFS) nem végeznek normalizációt. Tehát ha én most itt beállítom, abból maximum baj lehet, de jó nem származik belőle.

  • 1030 megtekintés

( Szenti v | 2017. 12. 25., h – 14:32 )

1. Solarisban és újabban (>=10.3) a FreeBSD-ben is vannak Boot Environmentek, amelyekkel verziózhatóvá válik a /. Ezek az envek a rootpool/ROOT/$env_name alá kerülnek. FreeBSD alatt a telepítő a rootpool/ROOT/default néven hozza létre a /-t. Bootolásnál a bootloaderben kiválaszthatod, hogy a rootpool/ROOT alatt melyik datasetet mountolja /-ként (a többinek ilyenkor a canmount property-je false lesz). Így viszonylag fájdalommentesen lehet dist-upgrade-elni. A biztonság kedvéért megtartanám így.

2. Ez is Solarisos ragadvány. A FreeBSD telepítő nem is hozza létre alapból (itt a snapshotoló szkriptet is külön kell telepíteni; ruby függősége van). Ezek alapján neked sem lesz rá szükséged.

3. A több dataset használata azért jó, mert jól szeparálhatóvá válnak az egyes property-k. Külön compression-t, quota-t (stb.) állíthatsz be az egyes dataseteknek. És mivel van property öröklés is, ez különösen rugalmassá teszi a dolgot. Ha egy dataset alá pakolod, ezt a rugalmasságot veszíted el. FreeBSD alatt alapértelmezés szerint a /var-nak a canmount property-je false; ez az alábbiakat eredményezi:

* az alatta levő datasetek megkapják a /var prefixet a mountpointjukban
* öröklik a /var minden tulajdonságát
* a /var-ban található fájlok (leszámítva a gyerek datasetek fájljait) emiatt a root datasetben vannak

A 4. pontot passzolom.

1. Így értem, hogy mire jó. Viszont Linux alatt nem hiszem, hogy ki lehetne ezt választani bootkor. Szerintem csak snapshot alapú visszaállás van. Akkor meg jobb, ha csak rpool van simán sallangok nélkül, nem? Illetve eddig (lekopogom) sose volt olyan, hogy vissza kellett volna állni.

3. Nem hiszek a diszk kvótákban, jobban tartok az adatvesztéstől :).