Fórumok
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.
Hozzászólások
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.
250 GB-ot egy kicsit soknak érzem. Még relatív értékben is sok, majdnem 5% !
És a szolgáltatás tömkeleg sem kellene, hogy közrejátszon, hiszen üres fájlrendszerről beszélünk.
A 2Tb az egészen pontosan 256MB.
Biztos, hogy megabájt? :)
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
Jóv Anna... Késő vót :-P Negyed TB, alias 256GB...
És az mennyi 640K-ban? :D
De lentebb is ugyanez. Arra még nem kommenteltem rá, úgyhogy még átírhatod. :)
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 13.37 | 2.6.39.3-janos
Ú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.
A literes olaj sem literes :D Ez a számmisztika világa :D
Igen, azt is láttam hogy a literes olajat is 0,9re visszavették. Figyelni kell nagyon mert átdobnak a palánkon hamar.
Csak a számok :) A többi csak fölösleges tölteték és palást a számok szavaira. Nagyon kell figyelni.
+1. érdemesebb extentekkel számolni.
De azt ugye látod, hogy az 1000 vs 1024 problémát figyelembe vettem? Ott van a számításban, ezért vártam 5.45 TB-ot a 6 TB helyett.
zpool list "poolname"
es
zfs list "poolname"
milyen ertekeket ad vissza? De valoszinu hogy akkor a kulonbseg a minden disken levo metadata miatt van.
Néhány óra múlva a gép közelében leszek, akkor megnézem.
Ha tenyleg ez a gond akkor valamennyit visszakaphatsz a zfs metadata compression ki/be kapccsal:
http://docs.oracle.com/cd/E26505_01/html/E37386/chapterzfs-7.html
Í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.
http://cuddletech.com/blog/pivot/entry.php?id=1013
Elég régi cikk, viszont a lényeg az, hogy az allokáció hatékonyságának növelése érdekében a ZFS valamennyi helyet fenntart a poolban.
Ok, magyarul búcsút inthetek 250 Gb-nak, ami nem mellesleg sokkal nagyobb mint a jelenlegi rendszerwinyó. Mindezt azzal az indokkal, hogy "csak".
nem kötelező zfst használni...
Azt hittem kötelező.
Nem "csak", hanem a copy-on-write működés miatt mindig kell valamennyi szabad helynek maradnia, egyébként használhatatlanná lassul az egész.
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.
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.
Nem rád gondoltam.
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.
snapshot nem maradt benne véletlen? (zfs list -t snapshot)
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
A 9223372036854775807 bájtos mediaméretből nekem a df csak ennyit mutat:
Filesystem 1024-blocks Used Avail Capacity Mounted on
mnt 8797192533835699 31 8797192533835668 0% /mnt
191 Petabájtot vesztettem el a ZFS miatt!
D'oh.
--
zsebHUP-ot használok!
250Gb az nagyjából 32GB... Ha ez sokkal nagyobb,mint a jelenlegi rendszervinyód, akkor gratulálok :-)
ez már egy kicsit kezd unalmas lenni...
zakuszka :D Szeretem :)
Szerintem nem csak a hdd gyártók szerint 1000. A megawatt sem 1024 W. Ugyanúgy SI prefix mind. Amire te gondolsz az a Mi prefix lesz szvsz.
off:Értem én hogy gőzgép de mi hajtja?:D
Megszokni nem tudom egyszerűen hogy igy van,de nem vitatom hogy nincs igazad. Csak megszoktam hogy 1 giga memória az 1024 mega, de ez már storagera nem igaz.Majd kinövöm.
Valahogy a memóriagyártóknál a 8 megás modul 8 MiB...
KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey
holokauszt karpotlas aldozata lett
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.
Nekem is ez volt az első gondolatom, "kilóra" stimmelt is volna, hiszen 5% az alapbeállítás. De zfs-nél nincs ilyen, a tune2fs nem is látja.
> De zfs-nél nincs ilyen, a tune2fs nem is látja.
Hat mivel meg a neveben is benne van, hogy az Ext2-hoz keszult joszag, ezen nagyon nem csodalkoznek.
Nos, nem is csodálkoztam :)
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.
Tudtommal a zfs alapból nem az egész lemezt használja raidz -hez. Pont azért, hogy ha tönkremegy egy lemez és ki akarod cserélni, akkor ne azon csússzál el hogy az a lemez kapacitásának a gyártó értelmezésbeli elérése miatt nem elég nagy.
Na ez már reálisnak tűnik, tudsz esetleg egy címet ahol ennek utánanézhetek vagy egy kulcsszót amire kereshetek?