On Sep 16, 2009, at 10:56 AM, 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.
Yes. Another use case is when the primary data has a high performance
requirement.
For example,
http://www.sun.com/software/products/messaging_srvr/wp_messaging_srvr_061909.pdf
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.
So the backup system must be running a version of ZFS compatible with
the clients.
This doesn't seem like a difficult requirement to me. If you were
truly paranoid, you
could even run the backups in virtual machines -- one per client.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
