EE> My main question is: does anyone have experience doing this in EE> production? It looks good on html and man pages, but I would like to EE> know if there are any caveats I should be aware of. Various threads EE> I've read in the alias archives do not really seem to talk about EE> people's experiences with implementing it.
There are a number of issues with 'zfs recv' which were fixed in Nevada build 53, so I would recommend that you use that or later. (see bugs 6468748 6490104 6490105 6490829.)
There's also a number of areas where performance could be improved, which hopefully I'll be able to get to soon.
btw: I haven't looked at zfs send/recv code (yet) but it looks like zfs send is traversing meta-data - it probably would be much faster if it would send/read data linearly - perhaps upto some specified buffer size, I wouldn't mind to design 2GB of RAM just for replication if it would speed it up considerably.
Yes, zfs send traverses metadata, and this is exactly what makes it so fast. It isn't possible to know what's changed (or, in fact, read anything from a ZFS storage pool) without traversing the metadata.
When doing remote replication, more memory will help, because then we will be able to keep more of the recent changes cached in memory and not have to read them off disk.
EE> Additionally, are there any plans for tools to facilitate such a EE> system? Something along the lines of a zfsreplicated service, which EE> could be more robust than a cron job?
I'm working on 'zfs send -r', which will allow you to easily send all the changes in a whole tree of filesystems (including properties, clones, 'zfs rename's, etc).
We're thinking about how to make a better replicated "service" than making you roll your own shell scripts / cron jobs, but I'm not sure when that will be ready.
I'm also thinking about writing simple daemon which would make use of libzfs and send/recv streams between hosts instead of scripts and command line tools. But it's after I'll have first conclusions about send/recv approach.
Have fun, but keep in mind that libzfs is a private interface, so it can change at any time, thus breaking your daemon. zfs(1m) is the supported interface.
--matt _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
