zfs discuss - Oct 2012 - zfs send to older version

Hi,

I''ve been using a Solaris 10 update 9 machine for some time to
replicate filesystems from different servers through zfs send|ssh zfs receive.
This was done to store  disaster recovery pools. The DR zpools are made from 
sparse files (to allow for easy/efficient backup to tape).

Now I''ve installed a Solaris 11 machine and a SmartOS one.
When I try to replicate the pools from those machines, I get an error because
filesystem/pool version don''t support some features/properties on the
solaris 10u9.
Is there a way (apart from rsync) to send a snapshot from a newer zpool to an
older one?

Thanks,

Michel

On 10/18/12 21:09, Michel Jansens wrote:
> Hi,
>
> I''ve been using a Solaris 10 update 9 machine for some time to
replicate filesystems from different servers through zfs send|ssh zfs receive.
> This was done to store  disaster recovery pools. The DR zpools are made
from  sparse files (to allow for easy/efficient backup to tape).
>
> Now I''ve installed a Solaris 11 machine and a SmartOS one.
> When I try to replicate the pools from those machines, I get an error
because filesystem/pool version don''t support some features/properties
on the solaris 10u9.
> Is there a way (apart from rsync) to send a snapshot from a newer zpool to
an older one?
You have to create pools/filesystems with the older versions used by the 
destination machine.

-- 
Ian.

>On 10/18/12 21:09, Michel Jansens wrote:
>> Hi,
>>
>> I''ve been using a Solaris 10 update 9 machine for some time to
replicate filesystems from different servers through zfs send|ssh zfs receive.
>> This was done to store  disaster recovery pools. The DR zpools are made
from  sparse files (to allow for easy/efficient backup to tape).
>>
>> Now I''ve installed a Solaris 11 machine and a SmartOS one.
>> When I try to replicate the pools from those machines, I get an error
because filesystem/pool version don''t support some features/properties
on the solaris 10u9.
>> Is there a way (apart from rsync) to send a snapshot from a newer zpool
to an older one?
>
>You have to create pools/filesystems with the older versions used by the 
>destination machine.
>
Thanks Ian,

One thing that is annoying though with running old pool version on Solaris is
that "zpool status -x" doesn''t return ''all pools are
healthy''.
And I wonder how SmartOS or Solaris 11 will react with Solaris 10 update 9
version filesystem for zones or KVM...
Also hearing about the new "feature flags", I have a feeling that
there is a risk of ZFS world being more and more fragmented.
At some point, people will bitterly regret some "zpool upgrade" with
no way back.
In that fragmented world, some common exchange (replication) format would be
reassuring.

In this respect, I suppose Arne Jansen''s "zfs fits-send"
portable streams is good news, though it''s write only (to BTRFS), And
it looks like a filesystem only feature  (not for volumes)

Michel
>-- 
>Ian.
>
>_______________________________________________
>zfs-discuss mailing list
>zfs-discuss at opensolaris.org
>http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
>

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Ian Collins
> 
> You have to create pools/filesystems with the older versions used by the
> destination machine.
Apparently "zpool create -d -o version=28" you might want to do on the
new system...  (I just wrote 28, but make sure it matches the latest version
supported by your receiving system.)  You might have to do something similar to
use an older ZFS version too.  And then you should be able to send from the new
to the old system.

On Oct 19, 2012, at 1:04 AM, Michel Jansens <michel.jansens at ulb.ac.be>
wrote:
>> On 10/18/12 21:09, Michel Jansens wrote:
>>> Hi,
>>> 
>>> I''ve been using a Solaris 10 update 9 machine for some
time to replicate filesystems from different servers through zfs send|ssh zfs
receive.
>>> This was done to store  disaster recovery pools. The DR zpools are
made from  sparse files (to allow for easy/efficient backup to tape).
>>> 
>>> Now I''ve installed a Solaris 11 machine and a SmartOS one.
>>> When I try to replicate the pools from those machines, I get an
error because filesystem/pool version don''t support some
features/properties on the solaris 10u9.
>>> Is there a way (apart from rsync) to send a snapshot from a newer
zpool to an older one?
>> 
>> You have to create pools/filesystems with the older versions used by
the
>> destination machine.
>> 
> Thanks Ian,
> 
> One thing that is annoying though with running old pool version on Solaris
is that "zpool status -x" doesn''t return ''all pools
are healthy''.
> And I wonder how SmartOS or Solaris 11 will react with Solaris 10 update 9
version filesystem for zones or KVM...
> Also hearing about the new "feature flags", I have a feeling that
there is a risk of ZFS world being more and more fragmented.
Feature flags offers a sane method to deal with the existing fragmentation.
Everyone will have it, except Oracle Solaris.
> At some point, people will bitterly regret some "zpool upgrade"
with no way back.
uhm... and how is that different than anything else in the software world?
> In that fragmented world, some common exchange (replication) format would
be reassuring.
> 
> In this respect, I suppose Arne Jansen''s "zfs fits-send"
portable streams is good news, though it''s write only (to BTRFS), And
it looks like a filesystem only feature  (not for volumes)
FITS is interesting for those file systems that support snapshots. If the market
demands, there could be some interesting work done for interop with ReFS
and others.
 -- richard

--

Richard.Elling at RichardElling.com
+1-760-896-4422









-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20121019/c9f305a7/attachment-0001.html>

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Richard Elling
> 
>> At some point, people will bitterly regret some "zpool
upgrade" with no way
>> back.
> 
> uhm... and how is that different than anything else in the software world?
No attempt at backward compatibility, and no downgrade path, not even by going
back to an older snapshot before the upgrade.

2012-10-20 3:59, Edward Ned Harvey 
(opensolarisisdeadlongliveopensolaris) ?????:
>> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
>> bounces at opensolaris.org] On Behalf Of Richard Elling
>>
>>> At some point, people will bitterly regret some "zpool
upgrade" with no way
>>> back.
>>
>> uhm... and how is that different than anything else in the software
world?
>
> No attempt at backward compatibility, and no downgrade path, not even by
going back to an older snapshot before the upgrade.

The way I understood feature flags, if your pool or dataset does
not have a feature enabled and/or used, another version of ZFS
should have no problem at least reading it properly, at least
those builds that know of the feature-flags concept. (Maybe the
versions limited to v28 would refuse to access a v5000 pool though).

Things written in an unknown on-disk format, be it some unknown
feature or an encrypted Solaris 11 dataset, seem like trash to
the uneducated reader - nothing new here (except that with FF
you can know in advance what particular features are used on
this dataset, that your system is missing for RO or RW access).
Hopefully, modules with new ZFS features are also easier to
distribute and include onto other systems as needed.

HTH,
//Jim Klimov

On Oct 19, 2012, at 4:59 PM, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) <opensolarisisdeadlongliveopensolaris
at nedharvey.com> wrote:
>> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
>> bounces at opensolaris.org] On Behalf Of Richard Elling
>> 
>>> At some point, people will bitterly regret some "zpool
upgrade" with no way
>>> back.
>> 
>> uhm... and how is that different than anything else in the software
world?
> 
> No attempt at backward compatibility, and no downgrade path, not even by
going back to an older snapshot before the upgrade.
ZFS has a stellar record of backwards compatibility. The only break with
backwards
compatibility I can recall was a bug fix in the send stream somewhere around 
opensolaris b34.

Perhaps you are confusing backwards compatibility with forwards compatibility?
 -- richard

--

Richard.Elling at RichardElling.com
+1-760-896-4422









-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20121022/0441461b/attachment.html>

> From: Richard Elling [mailto:richard.elling at gmail.com]
> 
> At some point, people will bitterly regret some "zpool upgrade"
with no way
> back.
> 
> uhm... and how is that different than anything else in the software world?
> 
> No attempt at backward compatibility, and no downgrade path, not even by
> going back to an older snapshot before the upgrade.
> 
> ZFS has a stellar record of backwards compatibility. The only break with
> backwards
> compatibility I can recall was a bug fix in the send stream somewhere
around
> opensolaris b34.
> 
> Perhaps you are confusing backwards compatibility with forwards
> compatibility?
Semantics.  New version isn''t compatible with old version, or old
version isn''t compatible with new version.  Either way, same end
result.

Actually, I think there is a world of difference.

Backwards compatibility is something we all need. We need to be able to 
access content created in previous versions of software in newer 
versions.

You cannot expect an older version to be compatible with the new 
features in a later version. Those features did not exist when the 
software was written. You wouldn''t expect to be able to open a document
created in the latest version of MS Word (and saved in the latest 
format) in Word 95, would you?

The only thing I think Oracle should have done differently is to allow 
either a downgrade or creating a send stream in a lower version 
(reformatting the data where necessary, and disabling features which 
weren''t present). However, this would not be a simple addition, and it 
is probably not worth it for Oracle''s intended customers.

On 2012-10-23 14:01, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
>> From: Richard Elling [mailto:richard.elling at gmail.com [1]] At some
>> point, people will bitterly regret some "zpool upgrade" with
no way
>> back. uhm... and how is that different than anything else in the
>> software world? No attempt at backward compatibility, and no 
>> downgrade
>> path, not even by going back to an older snapshot before the 
>> upgrade.
>> ZFS has a stellar record of backwards compatibility. The only break
>> with backwards compatibility I can recall was a bug fix in the send
>> stream somewhere around opensolaris b34. Perhaps you are confusing
>> backwards compatibility with forwards compatibility?
> Semantics. New version isn''t compatible with old version, or old 
> version
> isn''t compatible with new version. Either way, same end result.
> _______________________________________________ zfs-discuss mailing 
> list
> zfs-discuss at opensolaris.org [2]
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss [3]

Links:
------
[1] mailto:richard.elling at gmail.com
[2] mailto:zfs-discuss at opensolaris.org
[3] http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Karl Wagner
> 
> The only thing I think Oracle should have done differently is to allow
> either a downgrade or creating a send stream in a lower version
> (reformatting the data where necessary, and disabling features which
> weren''t present). However, this would not be a simple addition,
and it
> is probably not worth it for Oracle''s intended customers.
So you have a backup server in production, that has storage and does a zfs send
to removable media, on periodic basis.  (I know I do.)

So you buy a new server, and it comes with a new version of zfs.  Now you
can''t backup your new server.

Or maybe you upgrade some other machine, and now you can''t back *it*
up.

The ability to either downgrade a pool, or send a stream that''s
compatible with an older version seems pretty obvious, as a missing feature.

I will comment on the irony, that right now, there''s another thread on
this list seeing a lot of attention, regarding how to receive a ''zfs
send'' data stream on non-ZFS systems.  But there is no discussion about
receiving on older zfs systems.

On 10/24/12 03:16, Edward Ned Harvey 
(opensolarisisdeadlongliveopensolaris) wrote:
>> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
>> bounces at opensolaris.org] On Behalf Of Karl Wagner
>>
>> The only thing I think Oracle should have done differently is to allow
>> either a downgrade or creating a send stream in a lower version
>> (reformatting the data where necessary, and disabling features which
>> weren''t present). However, this would not be a simple
addition, and it
>> is probably not worth it for Oracle''s intended customers.
>
> So you have a backup server in production, that has storage and does a zfs
send to removable media, on periodic basis.  (I know I do.)
>
> So you buy a new server, and it comes with a new version of zfs.  Now you
can''t backup your new server.
So in this case you should have a) created the pool with a version that 
matches the pool version of the backup server and b) make sure you 
create the ZFS file systems with a version that is supposed by the 
backup server.

zpool create -o version
zfs create -o version
ZFS has the functionality but it can''t guess as to what the intended 
usage is so the default behaviour is to create pools and versions using 
the highest version supported by the running software.

-- 
Darren J Moffat

On 10/24/12 3:59 AM, Darren J Moffat wrote:
> So in this case you should have a) created the pool with a version that
> matches the pool version of the backup server and b) make sure you
> create the ZFS file systems with a version that is supposed by the
> backup server.
And AI allows you to set the rpool version how, exactly?

*crickets*

-- 
Carson

On 10/24/12 17:44, Carson Gaspar wrote:
> On 10/24/12 3:59 AM, Darren J Moffat wrote:
>
>> So in this case you should have a) created the pool with a version that
>> matches the pool version of the backup server and b) make sure you
>> create the ZFS file systems with a version that is supposed by the
>> backup server.
>
> And AI allows you to set the rpool version how, exactly?
I haven''t personally tried this but I believe it should be possible 
since you can set other pool options at install time eg:

<pool_options>
	<option name="version" value="28" />
<pool_options>

similarly for datasets that your AI manifest creates for you:

<dataset_options>
	<option name="version" value="4" />
<dataset_options>

See /usr/share/install/target.dtd.1

-- 
Darren J Moffat