ZFS on Linux: kevesebb a hely

Linux-haladó

4 db. 2TB-os winyóból létrehoztam egy raidz1 pool-t. Úgy számoltam, hogy kb. 5.45TB méretű kellene, hogy legyen. Ehhez képest csak 5.2TB szabad hely van. Hova tűnt 250GB kapacitás? Tudok valamit állítani, hogy visszanyerjem? Most még akár a pool kukázása és újra létrehozása is játszik.

Az 5.45 TB így jött ki: 3 db. 2 terabyte kapacitás, de nem igazi terabyte 1024^4, hanem csak 1000^4. Számokkal ugyenez: 3 x 2 x (1000/1024)^4

A szabad kapacitást a df -h paranccsal nyertem ki.

A rendszer Ubuntu 12.04 3.5-ös kernellel és ubuntu-zfs csomaggal a ppa-ból.

Valójában 3 teljes winyó, és egy 2TB-os partíció egy 3TB-os winyón. De ez nem kéne, hogy számítson. Kínosan ügyeltem rá, hogy a partíció nagyobb legyen mint a hdd-k mérete.

  • 10540 megtekintés

( freeoli v | 2013. 05. 16., cs – 13:04 )

Egy picit sántít a problémád. A 2Tb nem teljesen 2Tb, mire megformázod bármire akkor még kevésbé főleg ha egy szolgáltatástömkeleggel megáldott fs-el teszed ami egyben logikai lemezkezelő is. Pontos okot nem tudok.

A konklúzió feltehetően az lesz, hogy ez van. Vegyél nagyobb lemezeket.

( Atekka | 2013. 05. 16., cs – 13:12 )

Újabban már az 1 giga nem 1024 mega hanem csak 1000 a hdd gyártók szerint. Ergo az 1 tera sem 1024 giga már akkor szerintem.Plussz még a formázás után is vesztesz.

Íme:

# zpool list zakuszka
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
zakuszka 7.25T 2.62T 4.63T 36% 1.00x ONLINE -

# zfs list zakuszka
NAME USED AVAIL REFER MOUNTPOINT
zakuszka 1.90T 3.28T 1.90T /media/zakuszka

# df -h /media/zakuszka/
Filesystem Size Used Avail Use% Mounted on
zakuszka 5.2T 2.0T 3.3T 37% /media/zakuszka

Én ebből annyit tudok kiolvasni, hogy a zpool még azt a méretet írja 4 winyóra, amit én is számoltam: 4*2*(1000/1024)^4, a zfs viszont már 5.2T lát (used+avail) De hogy hol veszett el a 250G azt nem látom.

A metadata compression meg be van kapcsolva alapértelmezetten, ha jól látom. Azzal nem sokat nyerek, ha kikapcsolom.

OK, megnéztem most alaposabban a cikket. Azt írja, hogy 1/64 részt tart fent a zfs a copy on write funkció miatt, ami 1.5% De nálam 4.5%, majdnem 4.6% "veszett el". Nagy az eltérés, még mindig hiányzik 170 GB.

Update: Egy virtuális gépen csináltam egy próbát kis méretű komponensekkel és megnéztem ott is a számokat. Ott szépen kijött a blogban említett 1/64 fenntartás. Teljesen ugyanaz a szoftverkörnyezet, csak kisebbek a komponensek. Valami nem kerek itt.

Off: a vicces kedvű kommentelőknek, akik azt hiszik vagizásból csinálom ezt, üzenem, hogy nem a saját szórakoztatásomra állítottam össze ezt a configot.

Abból indulsz ki, hogy tudod, mekkora pontosan a 2TB-s diszked.
Rakj az egyikre más fájlrendszert és nézd meg, tényleg annyi -e, mint amennyinek gondolod...

Ha rám gondoltál, nem humorból írtam, hogy nem kötelező.
Ha ennyire tele akarod tölteni a ZFS-t, akkor inkább ne használd, vagy rakj bele több diszket.
Elvileg 80% telítettség felett nem célszerű zfs-t üzemeltetni, mert nagyon sokat romlik a teljesítménye.

Extrém elméleti példa: Ha tényleg teljesen kifogyna a helyből, akkor pl. törölni sem tudnál belőle.

Úgy rémlik egyéb faktorok is befolyásolják a ZFS helyfoglalását, pl. clusterméret.

Abból indulsz ki, hogy tudod, mekkora pontosan a 2TB-s diszked.
Rakj az egyikre más fájlrendszert és nézd meg, tényleg annyi -e, mint amennyinek gondolod...

A ext4 helyfoglalásával van még közelebbi tapasztalatom, ott sikerült utánamenni a részleteknek. De az egy másik fájlrendszer, ami nem mérvadó. Azt, hogy pontosan mekkorák a diskek, azt tudom:


Size: 2000398934016 bytes, 2000.3 GB

A fent linkelt blogban leírják hogy 1/64-et fenntart a zfs és hogy miért teszi ezt. Kicsi méretekben (2GB-os merevlemezekkel virtualboxban) szépen kijön nekem is az 1/64. Az éles rendszeren viszont több mint 3-szor annyit eszik.

Ha rám gondoltál, nem humorból írtam, hogy nem kötelező.

Nem rád gondoltam.

Ha ennyire tele akarod tölteni a ZFS-t, akkor inkább ne használd, vagy rakj bele több diszket.
Elvileg 80% telítettség felett nem célszerű zfs-t üzemeltetni, mert nagyon sokat romlik a teljesítménye.

Extrém elméleti példa: Ha tényleg teljesen kifogyna a helyből, akkor pl. törölni sem tudnál belőle.

Úgy rémlik egyéb faktorok is befolyásolják a ZFS helyfoglalását, pl. clusterméret.

Erről nem tudtam. Ha ez igaz, akkor még jobban érdekelne, hogy hol az elveszett 4.5% kapacitás. Lehet tényleg a cluster méret a ludas.

Update:

Biztosra akartam menni, hogy tényleg nem az zavar be hogy az egyik komoponens egy partíció, míg a többi teljes winyó. Ezért átvariáltam, hogy a teljes winyót használja a 3TB-os egységen is. Lement a resilver, utána nyomtam export-import-ot (zfs növelés) de továbbra is csak 5.2-t látok az 5.45 helyett.

Nincs több ötletem. Végülis együtt lehet élni ezzel a kompromisszummal, de akkor is zavaró, hogy nem tudom miért van. És 170GB azért nem kevés.

Update 2:
Találtam egy ilyet, 6 db 1.5TB-os diskből épített raidz-t:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-May/056654.html
Bár ő a zpool list és zfs list közötti különbséget nem értette, de utánaszámolva az ő adatainak, nála is pontosan 1/64 csak a veszteség.

Nem snapshot. Nagyjából megvan a megoldás:

Másképpen viselkedik a zfs raidz1 ha 3 winyót használsz vagy ha 4-et. A teszt virtuális gépen 3 winyóval dolgoztam, ezért nem jött elő ott a jelenség. 4 winyó esetén már eleve kicsit nagyobb a veszteség mint 1/64, de még közel sem 4.5% mint nálam. Viszont létrehozáskor ashift=12 módosítást. Írják is a hivatalos howto-ban, hogy ez tárhely veszteséggel jár, de 3 winyó esetén NEM jár tárhely veszteséggel, 4 esetén már igen. 4-nél több hdd esetén nem tudom mi van, feltételezem még nagyobb a veszteség.

Összefoglalva, a megoldás az hogy 4 winyó és ashift=12 esetén a teljes várható kapacitásnál 4.6%-kal kevesebb lesz elérhető. A pontos okokat mondjuk még most sem tudom, de legalább sikerült reprodukálni :)

Update:
Vannak itt durva dolgok, van aki 2TB-ot veszített ezen:
http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013950.html

( uid_4278 | 2013. 05. 16., cs – 13:49 )

Nehany fajlrendszer lefoglal a juzerek elol par szazalek helyet a fragmentacio es egyeb dolgok konnyebb kezelese erdekeben. Ezt ki tudod kapcsolni pl a tune2fs -m 0 /dev/... -el vagy a fajlrendszered hasonlo tooljaval.

( Zsugabubus | 2013. 05. 16., cs – 14:04 )

A BTRFS is hasonló "bőkezűen" bánik a hellyel, ezek a túlcsicsázott fájlrendszerek úgy néz ki, ilyenek...sok a metaadat. Azóta vissza is tértem az ext4-hez, gyorsabb is, takarékosabb is.