Mukodni mukodik, csak ennyi (2G) memorianal a dedup tabla hamar eleri azt a meretet (a poolon elfoglalt blokkok szamatol fuggoen), hogy nem lesz eleg hely szamara a RAM-ban. Ennek koszonhetoen alacsony irasi sebesseg erheto el. Ha netrol toltok le, nalam az 5 Mbit lefele savszelt gond nelkul irja dedupolva. Ha irasi sebesseg kell nfs-en, akkor nem dedupolt tmp datasetre irok vagy a root poolra, azon sincs dedup. Ha vmit gyorsan ki kell irnom diszkre, de kesobb dedupolva akarom tarolni, akkor a ket pool kozotti adatmozgatast rsync-el szepen meg lehet oldani.
Ezeket a negativ mutatokat fokent a teljesitmenyfelvetel es a vas kis merete miatt hajlando voltam bevallalni.
zfs destroy-t hasznaltam korabban kevesebb rammal is, nalam nem jott elo ilyen problema most sem, lehet csak makom van/volt es nem teszteltem eleg alaposan.
Elfogadom, hogy vannak a zfs-nek hibai, nalam ez arrol szol, h a celjaimra a legmegfelelobb valasztas. Amugy minden baja ellenere enterprise szinten is helytallo storage epitheto zfs-el, barmennyire is utaljak itt sokan.
Hogy az elmult hetek hirei utan a zfs fejlesztese milyen iranyt vesz gozom sincs. Mar jelen allapotaban befagyasztva is hasznalhato lesz sokak szamara akar FreeBSD-vel, akar Illumos-el, akar Solaris Express-el.