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.
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
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
