Re: Best method to limit snapshot/clone space overhead

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Jan


> On 24 Jul 2015, at 21:38, Reistlin <reistlin87@xxxxxxxxx> wrote:
> 
> Hi! Did you try ZFS and deduplication mechanism? It could radically decrease writes while COW.
> 
> _______________________________________________
> ceph-users mailing list
> ceph-users@xxxxxxxxxxxxxx
> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux