On Wed, Dec 17, 2008 at 08:51:54AM -0800, Niall Power wrote: > > What serious compat issues ? There has been one and > > only one > > incompatible change in the stream format and that > > only impacted really > > really early (before S10 FCS IIRC) adopters. > > Here are the issues that I am aware: > - Running "zfs upgrade" on a zfs filesystem will cause the "zfs send" > stream output format to be incompatible with older versions of the > software. This is according to the zfs man page. - Again from the > zfs man page: > "The format of the stream is evolving. No backwards com- > patibility is guaranteed. You may not be able to receive > your streams on future versions of ZFS." > So while the stream format has only changed once in the past, it > doesn't provide much reassurance that it won't change in the > future. This basically rules out network backups unless the remote > target is running a compatible verisons of ZFS since file blobs of > the stream maybe incompatible in the future.
The solution to this is to recv the stream immediately. So you have a disk for backups, right? Make it a pool, and zfs recv into it your zfs send backups. That means the zfs sends are transient, so no compatibility issues will arise. And you get a number of benefits that I described earlier today. > - From the thread I linked to in my original post, it was pointed out > that there is no error checking or checksum info in the file blobs of > the stream. I guess you mean that zfs recv doesn't verify the integrity of zfs send streams. But you can ensure the integrity of zfs send streams easily (e.g., use SSHv2 to move them around and always store them on ZFS datasets if you must store them). > These would appear to be real blockers for this approach for us. Am I > misunderstanding the issues? Or is there a viable solution that isn't > subject to these constraints? They are not blockers, not remotely for this use. See above. > > > * Resynchronisation is always optimal because See my reply to Ross today about this. Using send/recv you get to decide what snapshots to backup and what backed up snapshots to delete. You can't do the same with the mirroring approach. > We could create a partition on the disk that's > large enough to mirror the primary pool, leaving the > rest of the disk free for the user to use as they wish. Too complicated. Make the backup disk a pool and recv zfs sends streams into it. > > Really to do this properly with mirrors the "zpool > > split" capability Yes, but let's not do it with mirrors. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
