On Thu, Jan 16, 2020 at 4:34 PM Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote: > > On Fri, Jan 10, 2020 at 4:22 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > The current zfs2ceph implementation handles zvol sends and transforms > > them into rbd v1 import streams. I don't recall exactly the reason why > > we don't use v2 anymore, but I think there was some gaps that made it > > so it wasn't usable for our case back then (we were using Ceph > > Luminous). I'm unsure if this is improved now, though it wouldn't > > surprise me if it has. However, zvols aren't enough for us. Most of > > our ZFS datasets are in the ZFS filesystem form, not the ZVol block > > device form. Unfortunately, there is no import equivalent for CephFS, > > which blocked an implemented of this capability[3]. I had filed a > > request about it on the issue tracker, but it was rejected on the > > basis of something was being worked on[4]. However, I haven't seen > > something exactly like what I need land in CephFS yet. > > The reason I closed the ticket is that I thought the request was for a > mechanism to geo-replicate CephFS. There is on-going work to make that > feasible lead by Jan and Venky. > > If what you actually want is a way to import ZFS file systems, I would > tell you that rsync is the answer. If you have a binary stream of a > ZFS file system from `zfs export`, then you will need to import it > into a new zfs file system and rsync that. > That's fairly painful if I want to preserve all the history of ZFS snapshots while not retaining ZFS at the end of it. Yes, the problem is a lot simpler if I just kept ZFS even on the other end. But I want to be able to map a ZFS send stream to a CephFS import stream. That should be technically possible, albeit complicated, if CephFS supported import/export like RBD does. The idea, after all, is to be pure Ceph at the end. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
