Erik Trimble wrote:
Lori Alt wrote:
On 09/15/09 06:27, Luca Morettoni wrote:
On 09/15/09 02:07 PM, Mark J Musante wrote:
zfs create -o version=N pool/filesystem
is possible to implement into a future version of ZFS a "released"
send command, like:
# zfs send -r2 <snap> ...
to send a specific release (version 2 in the example) of the metadata?
I just created a RFE for this problem in general: 6882134. I'm not
sure the above suggestion is the best way to solve the problem, but
we do need some kind of support for inter-version send stream
readability.
Lori
I haven't see this specific problem, but it occurs to me thus:
For the reverse of the original problem, where (say) I back up a 'zfs
send' stream to tape, then later on, after upgrading my system, I want
to get that stream back.
Does 'zfs receive' support reading a version X stream and dumping it
into a version X+N zfs filesystem?
If not, frankly, that's a higher priority than the reverse.
I'm afraid that my answers yesterday, and the RFE I filed, have just
confused matters. I've learned some more about send stream
inter-version compatibility and found that the problem is not as
difficult as I thought:
There are two aspects to the stream versioning issue: the version of
the objects stored in the stream and the version of the stream format
itself. I was thinking that the object versioning was the harder
problem, but I discussed this with Matt Ahrens and he pointed out that
the existing zfs upgrade capability already copes with reading versions
of data object formats that are earlier than the version of the pool
into which the objects are being read. So as long as you're doing a
receive into a pool that has the same or greater version than the one
that was used to generate the send stream, the objects should be
interpreted correctly.
The second version issue, which is the stream format, is where we
haven't necessarily promised compatibility in the past, but so far, the
stream format has not changed. Changes are coming however for dedup.
We're looking at making those changes in such a way that earlier stream
formats will still be receivable into future releases.
So we're considering a refinement of the current policy of not
guaranteeing future readability of streams generated by earlier version
of ZFS. The time may have come where we know enough about how send
streams fit into overall ZFS versioning that we can make them more
useful by making a stronger assurance about future readability. So stay
tuned.
As for being able to read streams of a later format on an earlier
version of ZFS, I don't think that will ever be supported. In that
case, we really would have to somehow convert the format of the objects
stored within the send stream and we have no plans to implement anything
like that.
As for being able to selectively receive only parts of a send stream,
that's another subject, unrelated to versioning. As someone else
pointed out on this thread, that's one way in which zfs send/recv is
really not a 'backup' tool in the usual sense. If you need that kind of
functionality, zfs send/recv will not provide it for you. At some point,
we could perhaps implement a way to select the datasets from within a
send stream to receive, but given the way that objects are recorded in
send streams, it would be very difficult to restore individual files.
Lori
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
