No thanks at all. I think about ZFS deduplication in a slightly different aspect of using snapshots. We determined, that platter HDD work better with big object size. But it cause big performance overhead with snapshots. For example, you have 32Mb block size. And you have image snapshot. If only 1 byte in this object have to be written COW mechanism anyway will write 32 Mb of initial object, and only when will change this byte. It has big impact on performance of slow hdd. I am really sorry for my awful English. > 25 июля 2015 г., в 0:49, Jan Schermer <[email protected]> написал(а): > > We use ZFS for other purposes and deduplication is overrated - it is quite > useful with big block sizes (and assuming your data don’t “shift” in the > blocks), but you can usually achieve much higher space savings with > compression - and it usually is faster, too :-) You need lots and lots of RAM > for it to be reasonably fast and it’s usually cheaper to just get more drives > anyway. > But we're looking into creating a read-only replica of our pools on ZFS (once > we upgrade to Firefly which has primary affinity setting), but I don’t think > we’re even going to try it on a production r/w workload instead of xfs/ext4. > At least not until someone from Inktank/RH says it’s 100% safe and stable. > I can imagine OSD runing on top of ZFS using the ZFS clone semantics for RBD > image and pool clones/snapshots, that would be quite nice (and fast, proven > and just pretty much awesome). Maybe someone from RH will share this dream > (wink wink :)) > > Sorry for being slightly off-topic. In short ZFS is not the solution here and > now. But thank you for the idea.
_______________________________________________ ceph-users mailing list [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
