ZFS

FreeBSD-all

Halihó! 


Jan 17 00:06:38 freebsd kernel: WARNING: / was not properly dismounted
Jan 17 00:06:38 freebsd kernel: WARNING: ZFS is considered to be an experimental feature in FreeBSD.
Jan 17 00:06:38 freebsd kernel: ZFS filesystem version 6
Jan 17 00:06:38 freebsd kernel: ZFS storage pool version 6
Jan 17 00:06:38 freebsd kernel: IP Filter: v4.1.28 initialized.  Default = pass all, Logging = enabled
Jan 17 00:06:39 freebsd savecore: reboot after panic: kmem_malloc(118784): kmem_map too small: 1589731328 total allocated
Jan 17 00:06:39 freebsd savecore: writing core to vmcore.0

Négy hónap alatt elérte a megadott vm.kmem_size_max=1536M értéket, és tartott
egy egészségügyi sétát (gyk.: összeszarta magát :). Az a tippem, hogy valahol
van egy memory leak ZFS kapcsán, amely érzésre I/O érzékeny.

Érdekes lehet a CPU terhelés alakulása is a kernel panic előtt
(http://munin.javaforum.hu/system/system-cpu.html), ugyanis a system terhelés
folyamatosan magas volt, majd az éjjeli mentések lefutása kezdetén elszállt
az égbe. Illetve az is, hogy 13-án és 14-én egy szimpla `make world` 40-60
közötti load-ot generált...

Egyébként azt mondom, hogy viszonylag stabil de nagyon kényelmes... remélem
lesz arra példa, hogy a stabilitása magasabban lesz, mint a kényelmessége. :)

  • 1585 megtekintés

( trey | 2009. 01. 17., szo – 10:55 )

FreeBSD-s ZFS-sel vannak rossz tapasztalataim. IO megáll (egy egyszerű ls-re 40 másodpercet kell várni), egyszerű hálózati másolás képes katasztrófálisan belassulni (100 MB átmásolás 10-15 perc), stb.

--
trey @ gépház

Nálam semmi ilyen nem volt. Milyen paraméterekkel használtad? A ZFS FreeBSD alatt igen érzékeny a memóriára, nálam ezzel "stabil", ha négy hónap folyamatos működést annak veszünk.
vm.kmem_size_max=1536M
vm.kmem_size=1536M
vfs.zfs.arc_max=256M
vfs.zfs.vdev.cache.size=24M
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Amint látszik, ott sem én döntöttem, bár nekem az nem látszik ekkora kockázatnak. De ZFS eddig nem került a HUP alá. És szerintem belátható időn belül nem is fog. Bár ebben nem én döntök, ha bra bevállalja, akkor majd ő vállalja érte a felelősséget :) Én biztos, hogy nem tennék alá.

--
trey @ gépház

Én annyit mondok, hogy vannak vele stabilitási gondok, de ha az ember elfogadja, hogy a kernel "tetszőleges" időben pánikol, majd újraindul a gép és minden megy tovább, akkor nem okoz igazán nagy problémát. De ezek után biztos keresek valami indikátort, ami jelzi a kernel által lefoglalt memóriaterület méretét, és ha megközelíti a határértéket, akkor alkalmas időben újraindítom a gépet. 2-4 havonta úgyis van olyan security issue, ami miatt újra kell indítani, tehát nem okoz lelkifájdalmat, ha a kernel pánik nem egy véletlenszerű esemény, hanem megelőző jelei vannak, és a szerveren amúgy se futnak 7/24 igényű alkalmazások.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Nem tudom figyelted-e, hogy a "tetszőleges" szó idézőjelben volt. Úgy vettem észre, és ezt többen is észrevették, hogy a kernel panic oka a kernel memória elfogyása. Ez viszont mérhető, tehát a kernel panic nem tetszőleges időben következik be, hanem a kernel számára rendelkezésre álló memória elfogyásakor... egy csomó erőforrásra figyelni kell, amelyek elfogyása problémát okozhat, a kernel memóriát eddig nem kellett figyelni, ZFS esetén kell, amíg nem találnak rá megoldást.

Azt viszont ki tudom mondani, hogy adatvesztés és inkonzisztencia nem volt, s egyéb fájlrendszer probléma se, amely UFS esetén elő tud jönni... egyszerűen figyelnem kell a kernel memória méretére és a kernel panic nem "tetszőleges" időben jön, hanem előre jelezhető időben.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Amennyire emlékszem, Solarison a ZFS defaultban az (összes memória)-(1 GB) mennyiségű memóriát igyekszik fölzabálni, hogy minél hatékonyabban tudjon a puffereivel dolgozni. Nem tudom, hogy a freebsd-s portban ezen változtattak-e.

Mellesleg meg én sem értem, hogy miért szívsz FreeBSD-vel, ha ZFS-t akarsz. A(z Open)Solaris csomagkezelése egy dolog - de Solarist általában más okokból szoktak használni. :)

--
"Only an expert can deal with the problem"

Szívtam én eleget Solarissal... elég volt. :)

A Solaris alapvetően jó rendszer, de sajnos a Sun ezt is elhanyagolta az utóbbi időben, ült rajta, mint sok más technológián, most pedig igyekszik visszacsábítani azokat, akik leléptek. Nehéz feladat lesz... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

( shiloh | 2009. 01. 17., szo – 11:11 )

Miért freebsd-t használsz, ha ZFS-el akarsz dolgozni? Miért nem solarist?
Tényleg érdekel, nem kötekedem.

Próbáltam én több repót is... kevés csomag, elavult csomag, néhézkes telepítés és problémás frissítés volt a jellemző... de várom már a stabil OpenSolaris-t, hogy kipróbáljam azt is, de azt meg desktop célokra fejlesztik... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

( Mico v | 2009. 01. 17., szo – 20:20 )

Szerintem nincs teljesitmeny problema a zfs-el freebsd-n, tudok egy... fajlszerverrol, ami azota hoz egyaltalan hasznalhato sebesseget, hogy ufs-rol atkerult zfs-re. Szepen sorbarendezi az irast, olvasast, ahogy a marketing mondja. De csak ha ezt csinalod: vfs.zfs.prefetch_disable=1

A prefetech ugyanis freebsd-n nem tul jo. Ha bent van a prefetch akkor pont olyan tud lenni, mint amit trey meg masok irnak.

ARC, kmem es egyeb problemat meg nem lattam eddig, pedig atmegy rajta nehany kilobyte.