On 01/25/10 16:08, Daniel Carosone wrote:
On Mon, Jan 25, 2010 at 05:42:59PM -0500, Miles Nordin wrote:
et> You cannot import a stream into a zpool of earlier revision,
et> thought the reverse is possible.
This is very bad, because it means if your backup server is pool
version 22, then you cannot use it to back up pool version 15 clients:
you can backup, but then you can never restore.
It would be, yes.
Correct. It would be bad if it were true, but it's not. What matters
when doing receives of streams is that the version of the dataset (which
can differ between datasets on the same system and between datasets in
the same replication stream) be less than or equal to the version of the
zfs filesystem supported on the receiving system. The zfs filesystem
version supported on a system can be displayed with the command "zfs
upgrade" (with no further arguments).
The zfs filesystem version is different than the zpool version
(displayed by `zpool get version <poolname`>). You can send a stream
from one system to another even if the zpool version is lower on the
receiving system or pool. I verified that this works by replicating a
dataset from a system running build 129 (zpool version 22 and zfs
version 4 ) to a system running S10 update (zpool version 15 and zfs
version 4). Since they agree on the file system version, it works.
But when I try to send a stream from build 120 to S10 U6 (zfs version =
3), I get:
# zfs recv rpool/new < /net/x4200-brm-16/export/out.zar
Jan 27 17:44:36 v20z-brm-03 zfs: Mismatched versions: File system is
version 4 on-disk format, which is incompatible with this software
version 3!
The version of a zfs dataset (i.e. fileystem or zvol) is preserved
unless modified. So, I just did zfs send from S10 U6 (zfs version 3) to
S10 U8 (zfs version 4). This created a dataset and its snapshot on the
build 129 system. Then I checked the version of the dataset and
snapshot that was created:
# zfs get -r version rpool/new
NAME PROPERTY VALUE SOURCE
rpool/new version 3 -
rpool/n...@s1 version 3 -
So even though the current version of the zfs filesystem on the target
system is 4, the dataset created by the receive is 3, because that's the
version that was sent. Then I tried sending that dataset back to the U6
system, and it worked. So as long as the version of the *filesystem* is
compatible with the target system, you can do sends from, say, S10U8 to
S10U6, even though U8 has a higher zfs filesystem version number than U6.
Also, as someone pointed out, the stream version has to match too. So
if you use dedup (the -D option), that sets the "dedup" feature flag in
the stream header, which makes the stream only receivable on systems
that support stream dedup. But if you don't use dedup, the stream can
still be read on earlier version of zfs.
Lori
O
For backup to work the zfs send format needs to depend on the zfs
version only, not the pool version in which it's stored nor the kernel
version doing the sending.
I can send from b130 to b111, zpool 22 to 14. (Though not with the new
dedup send -D option, of course). I don't have S10 to test.
--
Dan.
------------------------------------------------------------------------
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
