- kqstor-zfs-announce - A "ZFS on Linux"-szal kapcsolatos bejelentések levelezési listája. Erre feliratkozva lehet értesülni pl. az új kiadásokról.
- kqstor-zfs-discuss - A termék használhatóságával, funkcionalitásával kapcsolatos levelezési lista.
- kqstor-zfs-dev - Fejlesztőknek szóló lista.
A listákon jelen vannak a KQ Stor Support Team tagjai.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Sok sok beszélgetés volt már a ZFS-ről, de mi az a kb X indok a használatára annak aki használja? Szétválasztható-e a solaris*-zfs páros?
- A hozzászóláshoz be kell jelentkezni
Szerintem nehezen. A COMSTAR is elég fontos a zfs fölé/köré, azt pedig nem portolták a többi rendszerbe.
- A hozzászóláshoz be kell jelentkezni
Annak, aki helyi fájlrendszerként akarja használni, miért lenne fontos a target mód? Annak meg, akinek fontos, használhatja az adott OS-ben lévőt (Linuxhoz is van ilyen).
Ennyi erővel azt is mondhattad volna, hogy nem, mert NFS szerver csak a Solarisban van.
suckIT szopás minden nap! Mi lesz az utolsó 2000 magánnyugdíjpénztár-taggal?
- A hozzászóláshoz be kell jelentkezni
Tulajdonképpen igazad van, attól eltekintve, hogy a ZFS alapú megoldásokat épp a target funkciót kiemelve árulják. Linuxos targetből meg szokás szerint van többféle, az egyik jó ebben, a másikat integrálták a kernelbe, a harmadikat meg valamelyik Enterprise Linux gyártó támogatja.
- A hozzászóláshoz be kell jelentkezni
Könnyű kezelhetősé, dedup, checksum, tömörítés, többféle adatbiztonsági szint, prefetch, l2arc, külön, állítható log device(ok), dinamikusság (módosításokban, beállításokban), viszonylag jó teljesítmény stb.
suckIT szopás minden nap! Mi lesz az utolsó 2000 magánnyugdíjpénztár-taggal?
- A hozzászóláshoz be kell jelentkezni
Tudom, hogy azt írod, "viszonylag", de gyakorlatilag azért mindenhez képest lassú tud lenni, még ez az új, kernel módú driver is.
A könnyű kezelhetőségért nem ájulok be, nekem az eddigi megoldások is könnyen kezelhetőek, dedup nem tudom, milyen szinten működik ebben a driverben, de majd meglátjuk.
Összességében nem értem ezt a ZFS hype-ot, egy rohadt nagy ígéretlufi volt, ami amint dolgozni kellett volna vele, kidurrant, és kiderült, hogy sok szempontból trágya, és van, ahol még a jó öreg UFS is megveri.
- A hozzászóláshoz be kell jelentkezni
Nem tudom, hogy csak a Linuxos zfs-ről beszélsz, vagy a zfs-ről általában.
(open)Solarissal csináltam egy rsync mentő szervert 4-5 linux napi mentésére.
FS tömörítés és dedup, elég sok helyet spórol (dedup kb 21%-ot, a tömörítésen felül)
A checksum elég jó biztosíték, hogy a mentett adatokról ne a visszatöltéskor derüljön ki, hogy bithiba miatt kuka.
Mentések után automatikus snapshot, így veszett egyszerűen lehet a korábbi mentéseket elérni, és nevetségesen egyszerű a mentések rotálása.
File rendszerek adminisztrációs feladatai egyenként delegálhatók usereknek, szükség esetén fél perc alatt bővíthető, stb
Könnyű kezelhetőség: 1-2 óra alatt összeraktam az egészet, halál egyszerű scriptek, kevés hibalehetőség.
Sebesség: backup szervernél kb. lényegtelen.
- A hozzászóláshoz be kell jelentkezni
Miért éppen a lényeges dolgokat hagyod ki? Én inkább ezekre gondolnék: volume manager, copy on write, snapshot.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
Mert ezek alacsony buzz word pontot kaptak. :)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Egyfelől nem gondolkoztam percekig, másfelől pedig ezek egy része szinte mindenhol máshol megvan már, ill. a felsorolt listában belefér a könnyű használat kategóriába.
suckIT szopás minden nap! Mi lesz az utolsó 2000 magánnyugdíjpénztár-taggal?
- A hozzászóláshoz be kell jelentkezni
En zfs-fuse-t hasznalok linux alatt es a checksum az ami miatt hasznalom. Elotte tobbszor volt 4 diszkes raid5 tombon bithibam (a hibas es az eredeti file kozott egyetlen bit kulonbseg van), meguntam, es atcsinaltam zfs-re. Szamomra nagyon jo, ha valahol hibat eszlel, automatikusan kijavitja a redundans adatokbol. Ha pedig tobb diszken is hibas ugyanaz a resz, akkor a zpool status -v parancs szepen kiirja mely fileok a serultek, es ha olvasni probalod azt a filet, akkor IO errort dob a hibas reszen (kiprobaltam). Igaz teljesitmenybol buktam valamennyit, de megerte, mert a silent data corruption nalam nagy mumus.
- A hozzászóláshoz be kell jelentkezni
Ebbe milyen gyakran futsz? Vagy ez a karmad? :D Nekem meg nem siekrult hasonlot produkalnom /kopp-kopp-kopp/, se soft, se "hard" raid megvalositasnal.
- A hozzászóláshoz be kell jelentkezni
Nem mondom, hogy gyakran van, de nálunk csak kevés diszk pörög, ahol több van, ott az esélye is nagyobb. Rejtett (rejtve maradt) adatkorrupció miatt vesztettünk már adatot hardveres RAID vezérlővel, nem is egyszer.
Pld:
NAME STATE READ WRITE CKSUM
label/disk20-05 ONLINE 0 0 4
label/disk21-07 ONLINE 0 0 1
- A hozzászóláshoz be kell jelentkezni
Checksumot számolni a btrfs is tud.
Amint stabilnak nyilvánítják, adok a btrfs-nek egy esélyt. A ZFS-sel azért nem szimpatizálok, mert azt mondják róla, hogy túl sok RAM-ot igényel (GB-okat).
- A hozzászóláshoz be kell jelentkezni
ohhh, varj, btrfs-t mirol is masoltak? hmmmm, csak nem a ZFS-rol?!
___
info
- A hozzászóláshoz be kell jelentkezni
ohh, Arra gondolsz hogy a tervezekor mar ZFS hibait is figyelmbe vehettek ?
Mi hozzaszolasod ertelme ? Mert ez enyimenk sincs.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Az 1 GB feletti memoriareszt hasznalja az ARC cache-nek, de ennek a meretet egy kernel parameterrel lehet limitalni.
- A hozzászóláshoz be kell jelentkezni
A btrfs nem tud raid5-ot. Lehet alá tenni raid5-ot, de ezzel nem fogja tudni megjavitani a checksum error-okat.
A zfs-fuse most nekem 250MB RAM-ot eszik egy aktiv hasznalatban lévő 7TB RAIDZ pool-on.
Azt javaslom, hogy az "azt mondják róla" helyett sajat tapasztalatok alapjan dönts.
- A hozzászóláshoz be kell jelentkezni
Én azért nem nézném elégedetten hátradőlve, hogy a ZFS ismeretlen eredetű bithibákat javítgat a szerveren.. :)
A főmemória biztos vétlen..?
- A hozzászóláshoz be kell jelentkezni