Lori Alt wrote:
On 09/16/09 10:48, Marty Scholes wrote:
Lori Alt wrote:
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.
If that is true, then it at least makes sense to include a "zfs downgrade" and
"zpool downgrade" option, does it not?
Not necessarily. The existence of an upgrade function doesn't
automatically mean that downgrade should be provided. What would a
downgrade function do with, say, properties that weren't even defined
in the earlier version?
Some kind of downgrade could theoretically be done (with appropriate
messages about capabilities and fields that are not understood by the
earlier version of the coded), but I don't think its value would be
worth the effort, at least not in comparison to other work that needs
to be done.
Lori
In my earlier posting, I was more hypothesizing something that I've
heard folks talking about.
Personally, I don't dump zfs streams to tape. 'zfs send/recive' is not
(nor do I expect it to be) a dump/receive for zfs. Backups and archives
are to be done by appropriate backup software.
That said, it's becoming more and more common to design in a large disk
backup device (Thor/Thumper, in particular) as either a staging area for
backups, or as the incremental repository. Think of it as a variation
on VTL. A typical config for this is with the client machines doing
'zfs send' over to the Thumper, and the Backup Software running solely
on the Thumper to do archival stuff. Doing it this way also means it's
simple to replicate the Thumper's data elsewhere, so one can have
redundant on-line backups, from which it is trivial to get back stuff
quickly. Naturally, the bane of this kind of setup is zfs version
mismatch between the Thumper and the client(s). I can easily imagine
situations where the Thumper has a later version of zfs than a client,
as well as one where the Thumper has an earlier version than a client
(e.g. Thumper runs 2008.11, client A runs 2009.05, client B runs Solaris
10 Update 6). Some method of easily dealing with this problem would be
really good.
Personally, I would go with not changing 'zfs receive', and modifying
'zfs send' to be able to specify a zfs filesystem version during stream
creation. As per Lori's original RFE CR.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
