On 09/16/09 11:56, Erik Trimble wrote:
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.
But that's just moving the 'downgrade' problem from one machine to
another. I'm going to modify or delete the RFE, because what I thought
made sense before, doesn't.
lori
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
