Zrep incompatibility problem with OpenIndiana

G

ghandalf

n00b
Joined
Sep 17, 2011
Messages
17
Hello,

I had some problems with zrep and OpenIndiana. I contacted the author and he said, that zrep was created for Solaris 10 and 11.
The problem with OI is, that OI misses some zfs features, like “receive –x” and “receive –o” and the initialization of volume is not supported for OI and I don’t know why!

Here are the error messages what I get when using zrep:
Source-Server (192.168.10.200)
Copying of a directory:
Code: 
zrep.orig init tank/zrep_test_1 192.168.10.201 tank/zrep_test_1
[I]Setting properties on tank/zrep_test_1
Ancient local version of ZFS detected.
Creating destination filesystem as separate step
Creating snapshot tank/zrep_test_1@zrep_000000
Sending initial replication stream to 192.168.10.201:tank/zrep_test_1
Debug: Because you have old zfs support, setting remote properties by hand
Initialization copy of tank/zrep_test_1 to 192.168.10.201:tank/zrep_test_1 complete[/I]
Code: 
zrep.orig list -v tank/zrep_test_1
[I]tank/zrep_test_1:
sharenfs        on
compression     on
atime   off
snapdir hidden
aclmode passthrough
aclinherit      passthrough
nbmand  on
sharesmb        off
sync    disabled
zrep:dest-host  192.168.10.201
zrep:master     yes
zrep:dest-fs    tank/zrep_test_1
zrep:src-fs     tank/zrep_test_1
zrep:savecount  5
zrep:src-host   oi151a-1[/I]

Target-Server (192.168.10.201):
Code: 
zrep list -v tank/zrep_test_1
[I]tank/zrep_test_1:
readonly        on
zrep:dest-fs    tank/zrep_test_1
zrep:savecount  5
zrep:dest-host  tank/zrep_test_1
zrep:src-host   oi151a-1
zrep:src-fs     tank/zrep_test_1[/I]

Copying of a volume:
Source-Server (192.168.10.200)
Code: 
zrep.orig init tank/zrep_vol_test_1 192.168.10.201 tank/zrep_vol_test_1
[I]Sorry, your zfs is too old for zrep to handle volume initialization
Error: Please initialize volume target by hand, if you won't upgrade[/I]

I did some modifications to zrep that it sends also the properties to the destination server:

Zrep-Version 0.8.4:
Line 689:
Code: 
zfs send $snap |  ->  zfs send –p $snap |

Are there any problems with the OI zfs version using zfs send –p command and why should it only be used together with the recv –x flag?

After editing zrep, the properties are copied correctly:

Source-Server (192.168.10.200)

Code: 
zrep.orig.mod init tank/zrep_test_2_zrep_modified 192.168.10.201 [I]tank/zrep_test_2_zrep_modified
Setting properties on tank/zrep_test_2_zrep_modified
Ancient local version of ZFS detected.
Creating destination filesystem as separate step
Creating snapshot tank/zrep_test_2_zrep_modified@zrep_000000
Sending initial replication stream to 192.168.10.201:tank/zrep_test_2_zrep_modified
Debug: Because you have old zfs support, setting remote properties by hand
Initialization copy of tank/zrep_test_2_zrep_modified to 192.168.10.201:tank/zrep_test_2_zrep_modified complete[/I]


Code: 
zrep.orig.mod list -v tank/zrep_test_2_zrep_modified
[I]tank/zrep_test_2_zrep_modified:
sharenfs        on
compression     on
atime   off
snapdir hidden
aclmode passthrough
aclinherit      passthrough
nbmand  on
sharesmb        off
sync    always
zrep:master     yes
zrep:src-fs     tank/zrep_test_2_zrep_modified
zrep:dest-fs    tank/zrep_test_2_zrep_modified
zrep:dest-host  192.168.10.201
zrep:src-host   oi151a-1
zrep:savecount  5[/I]


Target-Server (192.168.10.201)

Code: 
zrep list -v tank/zrep_test_2_zrep_modified
[I]tank/zrep_test_2_zrep_modified:
sharenfs        on
compression     on
atime   off
readonly        on
snapdir hidden
aclmode passthrough
aclinherit      passthrough
nbmand  on
sharesmb        off
sync    always
zrep:dest-fs    tank/zrep_test_2_zrep_modified
zrep:dest-host  tank/zrep_test_2_zrep_modified
zrep:src-host   oi151a-1
zrep:savecount  5
zrep:src-fs     tank/zrep_test_2_zrep_modified[/I]

The initial copying of a volume is more complecate!

I commented out the following lines:
Code: 
638                 if ((! Z_HAS_O )) ; then
639                         print "Sorry, your zfs is too old for zrep to haandle volume initialization"
640                         zrep_errquit "Please initialize volume target byy hand, if you won't upgrade"
641                 fi

and added / edited the following code after line 688:
Code: 
                typeset FLAG
                if (( vol )) ; then
                        FLAG="-u"
                else
                        FLAG=""
                fi

                zfs send -pv $snap |
                  zrep_ssh $desthost zfs recv $READONLYPROP $FLAG -vF $destfs
        fi

The u flag should not mount the volume, but the code does not work. I get always the sme error:
Code: 
zrep.orig.mod init tank/zrep_vol_test_1 192.168.10.201 tank/zrep_vol_test_1
[I]Setting properties on tank/zrep_vol_test_1
Ancient local version of ZFS detected.
Creating destination filesystem as separate step
Creating snapshot tank/zrep_vol_test_1@zrep_000000
Sending initial replication stream to 192.168.10.201:tank/zrep_vol_test_1
[B]cannot mount 'tank/zrep_vol_test_1': Invalid argument[/B]
WARNING: Removing all zrep configs and snapshots from tank/zrep_vol_test_1
Continuing in 10 seconds
Destroying any zrep-related snapshots from tank/zrep_vol_test_1
Removing zrep-related properties from tank/zrep_vol_test_1
Error: Error transferring tank/zrep_vol_test_1@zrep_000000 to 192.168.10.201:tank/zrep_vol_test_1. Resetting[/I]

Does someone also has these problems and maybe, there is another solution?

The missing receive flags are already a bug / feature report:
https://www.illumos.org/issues/2745

Your sincerely
Ghandalf
 
Flintstone said:
zrep works great for me in OpenIndiana
Click to expand...

Hello,

do you really have no error message? Were you able to do a initial sync of a volume and on a zfs directory are the properties copied to the dest-server?

If yes, what OI Version do you use?
I use a5 and a7 and on both versions, I have that problem:
Code: 
Setting properties on tank/zrep_test_1
[B][SIZE="5"]Ancient local version of ZFS detected.[/SIZE][/B]
Creating destination filesystem as separate step
Creating snapshot tank/zrep_test_1@zrep_000000
Sending initial replication stream to 192.168.10.201:tank/zrep_test_1
[B][SIZE="5"]Debug: Because you have old zfs support, setting remote properties by hand[/SIZE][/B]
Initialization copy of tank/zrep_test_1 to 192.168.10.201:tank/zrep_test_1 complete

and

Code: 
zrep.orig init tank/zrep_vol_test_1 192.168.10.201 tank/zrep_vol_test_1
[B][SIZE="5"]Sorry, your zfs is too old for zrep to handle volume initialization
Error: Please initialize volume target by hand, if you won't upgrade[/SIZE][/B]

I know that there is no newer version than a7 and I even upgraded the pool to the newest version -> no luck:mad:
 
I have ZFS v28 on all my servers - donno if that counts.

Code: 
root@marty:/root# uname -a
SunOS marty 5.11 oi_151a5 i86pc i386 i86pc Solaris

Code: 
root@marty:/root# zfs create bowl/test
root@marty:/root# zrep -i bowl/test future backup/test
Setting properties on bowl/test
Ancient local version of ZFS detected.
Creating destination filesystem as separate step
Creating snapshot bowl/test@zrep_000000
Sending initial replication stream to future:backup/test
Debug: Because you have old zfs support, setting remote properties by hand
Initialization copy of bowl/test to future:backup/test complete
 
Sorry - yes I get the same problem with volumes. I don't use them though, why would you? (still using iscsi?)
 
To bad the licence isn't GPL, or we could get a fork going on this focusing on OI :)

Please submit a patch here if you manage to solve some of the issues!
 
"Too bad the license isn't GPL"

lol The GPL is like sarcoma that never goes into remission...
 
Hi,

Flintstone said:
Sorry - yes I get the same problem with volumes. I don't use them though, why would you? (still using iscsi?)
Click to expand...

yes we need iscsi! Is something wrong with iscsi? Are there any problems?
We use OpenVZ for our Webserver virtualization and I had no luck using the OI NFS server for hosting the OpenVZ data. With the linux NFS server, there is no problem, but this an other problem!

Flintstone said:
To bad the licence isn't GPL, or we could get a fork going on this focusing on OI :)

Please submit a patch here if you manage to solve some of the issues!
Click to expand...

I solved all the issues I have, but I don't know, how to create a patch. I implemented a special routine for OpenIndiana.
I could send you my edited version, but before that, I have some another questions:

The author of zrep said, it is not good to use some flags all the time, like:
Code: 
zfs send -p or -R
zfs receive -F
Why shouldn't I use these flags all the time and why should I only use the flag -p with the receive -x mountpoint option?
I have an other zfs backup script made by myself, where I always use the send -R flag and the receive -F flag.

Ghandalf
 
Hi folks,
the author of zrep here. I attempted to explain some of the issues and reasons to the original poster in our prior email discussion, but apparently, some concepts didnt get through.
I wanted to share the info here, lest some incorrect or incomplete information about zrep get propagated.

I put the limitation about replicating volumes into zrep, because in certain versions of ZFS in certain versions of solaris... if you use a particular combination of options in doing a zfs send and recv. It crashes.
Not the program. The Entire OS.
Sooo.. yeah.. bad. important to avoid. I decided to go with, "if it looks like an old version of ZFS, dont do it"

I meant to revisit the issue, to attempt to see if there was a better way to identify and avoid the crash cases. I also need to refresh my memory on the trigger circumstances. (I made some posts about it on comp.unix.solaris a while back, I think)
but it has kinda dropped off my radar. If it is important to other people, please give me a friendly nudge.

Now as for why zrep doesnt use send -p all the time: That is a design choice, to allow flexibility for the remote side. Sometimes, you dont WANT the remote side to have the same options as the live master. For example, you may want compression on a mostly idle standby system, and so you may also want to keep around lots of snapshots.
In contrast, you may want to disable compression on the master. which means you dont have room for as many snapshots.
Cant do that sort of thing, if you are going to be always replicating the compression property. Not to mention dedup!

If anyone else any further questions about zrep, please feel free to check out the docs now online at http://www.bolthole.com/solaris/zrep/zrep.documentation.html and/or drop me a note at my bolthole.com email

Philip Brown
 
You must log in or register to reply here.
Back
Top