zfs discuss - Sep 2008 - Unable to use zfs send/receive from NexentaStor 1.0.6 to Solaris 10 Update 5 x86

Dear all,

I''ve trying to replicate some ZFS folder from NexentaStor 1.0.6 to
Solaris 10 Update 5 x86 using Nexenta''s Auto-sync. However it does not
work.
Here I do some test by directly using the root shell of Nexenta for
simplification (instead of using the NMS GUI to do that).

Nexenta host : golf (192.168.3.17) :
root at golf:/etc/ssh# cat /etc/release
                         Nexenta Storage Appliance v1.0.6
           Copyright 2008 Nexenta Systems, Inc.  All Rights Reserved.
          Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
root at golf:/etc/ssh# uname -a
SunOS golf 5.11 NexentaOS_20080312 i86pc i386 i86pc Solaris

Solaris 10U5 : charlie (192.168.3.13) :
root at charlie # cat /etc/release
                        Solaris 10 5/08 s10x_u5wos_10 X86
           Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                             Assembled 24 March 2008
root at charlie # uname -a
SunOS charlie 5.10 Generic_127128-11 i86pc i386 i86pc


Here is the ZFS volume I need to replicate :

root at golf:/etc/ssh# zfs list |grep dedhi
data/work/dedhi                 68.3G   436G  68.3G 
/volumes/data/work/dedhi
data/work/dedhi at today               0      -  68.3G  -

Here is the ZFS on the target :
root at charlie # zfs list
NAME              USED  AVAIL  REFER  MOUNTPOINT
data              200G  93.3G  26.5K  /data
data/volume      26.9M   293G  26.9M  -
data/work          49K  93.3G  24.5K  /data/work

When I do the replication :
root at golf:/etc/ssh# zfs send data/work/dedhi at today|ssh 192.168.3.13 zfs
recv data/work/dedhi at today
cannot receive: invalid backup stream

No-login SSH is already established :
root at golf:/etc/ssh# ssh 192.168.3.13
Last login: Sun Sep 28 23:01:35 2008 from golf-ge
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
Sourcing //.profile-EIS.....

Any idea what is the source of the problem here? I remembered the last
time I did this between SPARC system I did not have any issues.
Unfortunately these are the only two x86 Solaris system I have now.

Thanks in advance,

Dedhi

On 28 September, 2008 - Dedhi Sujatmiko sent me these 2,3K bytes:
> Dear all,
...
> When I do the replication :
> root at golf:/etc/ssh# zfs send data/work/dedhi at today|ssh 192.168.3.13
zfs
> recv data/work/dedhi at today
> cannot receive: invalid backup stream
> 
> No-login SSH is already established :
> root at golf:/etc/ssh# ssh 192.168.3.13
> Last login: Sun Sep 28 23:01:35 2008 from golf-ge
> Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
> Sourcing //.profile-EIS.....
This "Sourcing ..." is probably messing up.

Try ''ssh 192.168.3.13 pwd'', that should _only_ echo the
directory,
nothing else, or it will probably mess up the stream.

Make sure it only echoes stuff when it''s an interactive login.

/Tomas
-- 
Tomas ?gren, stric at acc.umu.se, http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Ume?
`- Sysadmin at {cs,acc}.umu.se

Tomas ?gren wrote:
> This "Sourcing ..." is probably messing up.
>
> Try ''ssh 192.168.3.13 pwd'', that should _only_ echo the
directory,
> nothing else, or it will probably mess up the stream.
>
> Make sure it only echoes stuff when it''s an interactive login.
Thanks for sharing the idea.
However that is not the source of the problem here, the ssh direct is
not affected by profile sourcing :

root at golf:/export/home/admin# ssh 192.168.2.13
Last login: Sun Sep 28 23:59:51 2008 from 192.168.2.101
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
Sourcing //.profile-EIS.....
root at charlie # exit
Connection to 192.168.2.13 closed.
root at golf:/export/home/admin# ssh 192.168.2.13 pwd
/
root at golf:/export/home/admin# ssh 192.168.2.13 ''uname -a''
SunOS charlie 5.10 Generic_127128-11 i86pc i386 i86pc
root at golf:/export/home/admin#

regards,

Dedhi

Dedhi Sujatmiko wrote:
> When I do the replication :
> root at golf:/etc/ssh# zfs send data/work/dedhi at today|ssh 192.168.3.13
zfs
> recv data/work/dedhi at today
> cannot receive: invalid backup stream
I just realized that the ZFS version being used in Solaris 10 U5 and
NexentaStor 1.0.6 is far far different, possibly this is the cause of
the incompatibilities.

root at golf:/export/home/admin# zpool upgrade
This system is currently running ZFS pool version 10. -->NexentaStor 1.0.6
All pools are formatted using this version.

root at charlie # zpool upgrade
This system is currently running ZFS version 4. --> Solaris 10 U5
All pools are formatted using this version.


In that case, I will use back the rsync+SSH method replication.

Dedhi Sujatmiko wrote:
> Dedhi Sujatmiko wrote:
>   
>> When I do the replication :
>> root at golf:/etc/ssh# zfs send data/work/dedhi at today|ssh
192.168.3.13 zfs
>> recv data/work/dedhi at today
>> cannot receive: invalid backup stream
>>     
>
> I just realized that the ZFS version being used in Solaris 10 U5 and
> NexentaStor 1.0.6 is far far different, possibly this is the cause of
> the incompatibilities.
>
> root at golf:/export/home/admin# zpool upgrade
> This system is currently running ZFS pool version 10. -->NexentaStor
1.0.6
> All pools are formatted using this version.
>
> root at charlie # zpool upgrade
> This system is currently running ZFS version 4. --> Solaris 10 U5
> All pools are formatted using this version.
>   
The pool version has no impact on the send/receive stream protocol,
which has its own versioning.

If or when there is a change that causes compatibility issues, it
will be noted in the flag days, release notes, and other docs.

The last and such note is:
http://www.opensolaris.org/os/community/on/flag-days/pages/2008042301/
Which should not apply, since b35 was circa February 2006.  Even though
Solaris 10 update 5 seems (and is) ancient, it isn''t that old.

The recursive (-R) flag to zfs send was introduced in b77, circa October,
2007, which was after the Solaris 10 update 5 cutoff date.  However,
notes from the PSARC 2007/574 case indicate that this "should just
work,"
as you have described.
http://www.opensolaris.org/os/community/arc/caselog/2007/574/mail

If it can be reproduced and is still not working, then please file a bug.
>
> In that case, I will use back the rsync+SSH method replication.
>   
That will work, too.
 -- richard