Sziasztok!
Egy olyan problémába ütköztem, hogy adott egy levelező szerver melyben van 8db diszk zfs fájlrendszerrel és van egy backup szerver jelen pillanatban 6db diszkkel, szintén zfs fájlrendszerrel.
Levelező szerver pool-ja:
pool: srv-data
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
srv-data ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda6 ONLINE 0 0 0
sdd6 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
sdc6 ONLINE 0 0 0
sdb6 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
sdh6 ONLINE 0 0 0
sdg6 ONLINE 0 0 0
mirror-3 ONLINE 0 0 0
sdf6 ONLINE 0 0 0
sde6 ONLINE 0 0 0
Backup szerver pool-ja:
pool: srv-data
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
srv-data ONLINE 0 0 0
mirror-0 ONLINE 0 0 0lta.
sdb5 ONLINE 0 0 0
sdc5 ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
sdd5 ONLINE 0 0 0
sda5 ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
sdf5 ONLINE 0 0 0
sde5 ONLINE 0 0 0
A levelező szerverről a leveleket szeretném lementeni. A levelek mérete elméletileg kb. 4TB. Ezt a du -sh is igazolta.
root@mail:~# zfs list
NAME USED AVAIL REFER MOUNTPOINT
srv-data 4,14T 1,46T 96K /
srv-data/home 109G 1,46T 109G /home
srv-data/srv 49,8G 1,46T 49,7G /srv
srv-data/vmail 3,99T 1,46T 3,99T /home/vmail
root@mail:~# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
srv-data 5,78T 4,14T 1,64T - 55% 71% 1.00x ONLINE -
backup szerver datasetje így néz ki:
root@backupserver:~/Install# zfs list
NAME USED AVAIL REFER MOUNTPOINT
srv-data 4.76T 418G 96K /srv-dat
srv-data/home 4.76T 418G 4.76T /home
root@backupserver:~# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
srv-data 5.30T 4.76T 546G - - 46% 89% 1.00x ONLINE -
A probléma az, hogy mikor megpróbáltam a közel 4TB-ot átszinkronizálni egyszerűen nem fér fel az srv-data/home dataset-re. Kb. 95%-nál már 5,2TB-ot mutatott ugyanaz az adatmennyiség.
Előtte egy másik szerverrel is próbáltam, de azon ext4 fájlrendszer van, de ugyanezt produkálta. A tömörítés mindkettőnél megegyezik:
root@mail:~# zfs get all srv-data/vmail | grep compress
srv-data/vmail compressratio 1.15x -
srv-data/vmail compression lz4 inherited from srv-data
srv-data/vmail refcompressratio 1.15x
root@backupserver:~# zfs get all srv-data/home | grep compress
srv-data/home compressratio 1.13x -
srv-data/home compression lz4 inherited from srv-data
srv-data/home refcompressratio 1.13x
Ez mitől lehet? Mi az amit nem tudok a zfs-ről?
Hozzászólások
compression?
Mind a kettő szerveren be van állítva és ugyanaz. lz4.
es hogyan gondoltad, hogy a 418G AVAIL helyre betuszkolod a 4T adatot?
Az 5,3TB-ra szeretném tenni. Most azért látszik így, mert az adatok egy része rajta van, de töröltem róla, mert szinkronizálás közben még nem ment át az összes adat és megtelt az 5,3T.
es mennyi volt indulaskor az avail? mekkora az ashift? mekkora a recordsize?
minden masra javaslom hasznalni a tar nevu nagy sikeru szamitogepes programot, ha nem akarod, hogy elvesszen az a jo sok hely a par bajtos levelek tarolasakor :)
Teljesen üresek voltak a diszkek. Friss telepítés és semmi más nem volt rajta.
nem ez volt a kerdes. nezz utana a recordsize, ashift-nek es, hogy mi az a metadata. nem csak a file-ok tartalmat tarolod egy filerendszeren. plusz torleskor pl. nem lesz egybol szabad az AVAIL zfs eseten, mert az a hatterben zajlik.
Akkor miért történ ugyanez korábban ext4-en egy másik szerveren? At gyanítom, hogy más is szinkronizálódik, de nem tudom, hogy mi.
Már a recordsize-t is megnéztem korábban és mind a két szerveren 128K.
azt neked kellene megmondanod, te kezeld az FS-eket. ext4 eseten sem fix a blocksize/inode
lenyeg, hogy ott az ALLOC, az a helyfoglalas (data+metadata+lost space summa), azt kell megvizsgalnod.
ZFS-en nincs közvetlen összefüggés a file mérete, a recordsize és a tényleges helyfoglalás között, mint más, kötött blokkszámú és blokkméretű FS-en...
Itt a recordsize elsősorban az IO sebességet befolyásolja, a tényleges helyfoglalást nem. Minél inkább random az elésér módja, annál inkább kell közel tenni a reckordzize-t a valódi adatblokk mérethez, és minél inkább szekvenciális, annál inkább 1M felé kell állítani a recordsize-t az adatdarabok méretétől függetlenül. 128k recordsize mellett egy rekordba annyi file lesz, ami kiadja a 128k-t, nem 1 file és a felmaradó üresség a 128k-ig...
de, van. nincs ingyenebed :D
Nem az a gond, hogy a record-ot ne lehetne fragmentalni, hanem ennek bizony eleg nagy helyigenye van (metadata), mert tudnod kell hol vannak a fileok. Esetunkben elmondasbol levelezes van itt, jo esellyel kurvasok kicsi file-rol beszelgetunk.
(Nem mellesleg agyonlovod a performanciat, de az most mindegy.)
Nem vitázni szeretnék, de ez így még nem pontos.
Természetesen van overhead, de már alapbeállításokkal is sokkal kevesebb, mint egy kötött blokkméretű FS-en. Pláne, ha a tömörítés aktív (alapból aktív), akkor a ZFS rekordok a már tömörített adatot tartalmazzák. Ha több kicsi állományból jön össze egy rekordnyi tömörítvény, akkor többől rakja össze, nem lesznek "lyukak" a rekordokban kis állományok esetén.
A metaadat pedig (más FS-sel ellentétben) kiszervezhető gyorsabb adattárolóra, hogy a teljesítmény növelhető legyen a teljes pool gyors tárolóra cserélése nélkül.
Metaadat meg minden FS-en van, az nem a ZFS jellegzetessége/vesztesége, hanem az állománytárolás velejárója. A ZFS metaadat méret függ a recordsize értéktől és az állományok számától. Az "alap" ajánlás ennek számítására a pool méretének 0.3%-a (ez nyilván a default 128k recordsize és nem több tízmilliós állományszámra érvényes). Nyilván nagyon sok állomány és/vagy kis recordsize ennél jelentősen nagyobb tárhelyet is igényelhet a metaadatnak, de ebből látszik, hogy azért nem olyan óriási a metaadat helyfoglalása. Inkább annak elérési sebessége számíthat. De az ARC tárolja a metaadatot is, így ha pl. végigolvastatod a pool könyvtárszerkezetét egyszer, akkor onnanról az ARC-ból memória sebességgel érhető el az összes metaadat nagyjából a gép újraindításáig.
Aki levelezést tárol, az általában tudja, hogy nem lesz teljesítmény (vagy legalábbis nem akkora, mintha darabonként nagyobb és kevesebb állományt tárolna azonos helyfoglalás mellett). De ez nem is volt kérdés.
420GB allocated as of yesterday, 70GB being metadata. == 0.3%?
nem veszed figyelembe a use case-t
Total Metadata
153358336 Bytes
0.14 GiB
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 4.56G 211G 104K /rpool
ez egy linux telepites, ez kapasbol 10x 0.3% a USED-hoz kepest. szoval nem tudom hol ajanlottak neked a .3%-ot, de erost fugg az attol, hogy mi van a poolodban.
Egyáltalán nem ezt írja a likelt fórum bejegyzés...
A kérdező elcsodálkozik, hogy akkor neki 1 GB metaadat van 1 TB adatonként? Erre válaszolja az illető, hogy a special vdev-en nem csak metaadat van neki, hanem kis állományok is tárolhatók rajta, és nála emiatt jelenleg a special vdev foglaltsága 420 GB, ebből 70 GB a metaadat - nyilván a további 350 GB kis méretű fájl (állítása szerint több millió). Nem a pool foglaltsága 420 GB, hanem a special vdev-é...
akkor erre mit tudsz mondani?
ez is 0.3%?
Látom megragadtad a lényeget a válaszaimból. Nem a 0.3% a lényeg.
Az utolsó adatsornál azért láthatóan valami nem stimmel a kalkulációval, mert 11 TB-ból ~7 TB metaadat nekem kicsit soknak tűnik. Szerintem nincs az a kis rekordméret, fragmentálódás és sok állomány, hogy 4 TB adathoz 7 TB metaadat társuljon.
Itt a hivatkozás - ugyan úgy Level1-es bejegyzés - arról, hogy mi módon lehet megbecsülni a metadata méretet. Wendell írása, aki szerintem mindkettőnknél jobban ért a ZFS-hez (tőlem mindenképp jobban). Szerinte a 0.3% jó kiindulási alap, de persze nem szentírás, le is írja, mi mindentől függ a mérete.
Az írásom lényege az volt viszont, hogy a metaadat mérete a pool valós helyfoglalásához képest minden esetben kicsi, így nem a metaadatra fogy el a sok hely, bármennyi állomány is van a pool-ban.
Ez az utóbbi 58%-os adatod, ha valós, már rég nézegetni kellene, hogy mi történt azon a pool-on...
Nálam amit gyorsan el tudtam érni 0.09% és 0.18% a metaadat mérete az adat valós helyfoglaláshoz viszonyítva.
Ráadásul a kérdezőnek van egy ZFS pool-ja, benne a mentendő adatokkal. Ergo ismeri a teljes helyfoglalást és a metaadat méretet is könnyen ki tudja számolni. Szóval minden adat ismert, amiből megállapítható, hogy egy másik gépen lévő ZFS pool-ra átmásolható-e az adat (lesz-e elég hely az adat+metaadat mennyiségnek).
valos. nincs mit rajta nezegetni. latom megragadtad vegre a lenyeget "nem szentírás, le is írja, mi mindentől függ a mérete." :)
Normál esetben erre már nem válaszolnék, mert minek. Valaki rákontrázott az írásodra, ami ezek szerint nem tetszik, és most már csakazértis. Ezzel ugye egy beszélgetésben nem lehet mit kezdeni azon felül, hogy tisztázod a félreértést (ami miatt a rákontrázás keletkezett), vagy azt mondod, valóban, igazad van. Én meg a másik fél el tudom engedni, mert előre nem jutunk.
Ugye itt egyik sem történt. Egy - vélhetően - félreolvasás miatt linkelted, hogy 420 GB adathoz 70 GB meta tartozik. Erre írtam, hogy ez félreolvasás, mert a special-on van 420 GB, amiből 70 GB meta, a többi small file. A teljes dataset méretét nem ismerjük, nem adta meg a szerző.
Miért tartunk még mindig ott, hogy mennyi százaléka a meta a tényleges adanak, mikor ez csak egy általam idézett cikk részletbe kapaszkodás, amit én nem olvastam félre, és az eredeti szerző is írja, hogy amit ír, egy tapasztalati "ökölszabály", de a valós értéket sok dolog befolyásolja. Linkeltem is az írást.
Ráadásul az eredeti felvetés egyáltalán nem a metáról szólt, hanem arról, hogy mennyi tárhely veszik el egy FS-en a kis állományméret miatt, ami ZFS esetben eléggé csekély, normál esetben.
nem tudok mast mondani, minthogy teszteld akkor le semmint belekapaszkodsz, hogy valaki valahol azt irta, hogy 0.3%... lehet elorebb jutsz.
57M/155M hasznos adatra jut cca 40M/100M metadata. mert kis fileok. :)
szivesen, mostmar torlom a VM-et, a kov. kort otthon kell lefusd. :D
nincs a backupon snapshot? Az tudja enni a helyet, ha felül akarod írni...
Van, de minimális és csak a rendszerről.
root@backupserver:~# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
srv-sys/ROOT/debian@install 10.9M - 784M -
srv-sys/var/lib/dpkg@install 1.12M - 10.2M -
Deduplikáció esetleg? Nem vagyok ZFS guru, korábban egy FreeNAS szerveren használtam. Nem okozhat ilyet ha a forrásnál engedélyezve van, és a célnál pedig nincs?
Mind a két szerveren off.
root@mail:~# zfs get all srv-data/home | grep dedup
srv-data/home dedup off default
root@backupserver:~# zfs get all srv-data/home | grep dedup
srv-data/home dedup off default
Hogyan próbálod szinkronizálni? Nincsenek sparse fájlok?
rdiff-backup programmal csinálok teljes mentést, utána pedig különbségeket. Megnéztem azokat a fájlokat is amiket az rdiff készít, de a méretük összességében nem jelentős.
es a szamuk? (metadata)
Milyen fájlokat néztél meg? Az rdiff backup által készített fájlok mérete nem jelentős, 4 TB-t akarsz menteni, és megtelik a céloldalon a fájlrendszer???
Két ZFS pool esetében hogyan jött az ötlet, hogy ZFS send-receive vagy syncoid helyett rsync-rdiff legyen a backup eszköz?
Simán syncoid, és meg van oldva a kérdés, a hely sem lesz probléma, meg a sebesség sem. Ráadásul ha nem csak utolsó állapotot szerenél, akkor meg lehet tartani bármennyi előző snapshot-ot (a syncoid lekezeli) a backup-on.
418G hely van a backupon, nyilván nem fog ráférni.
Mivel van tele a home a backup serveren?
Ha szerinted üres (letörölted) és fogalmad sincs mi fogja a helyet akkor indítsd újra.
Gábriel Ákos
fentebb vegul kiderult, hogy nem is ugyanaz az adat source-dest viszonyban, mert rdiff-el a kedves forumtars :D innentol pedig mar a cim is felrevezeto, mert nem a dataset-et menti, hanem keszit egy mentest es csodalkozik, hogy a tobb file (tobb adat) tobb helyet is foglal.