zfs discuss - Feb 2009 - Send & Receive (and why does ''ls'' modify a snapshot?)

I am trying to keep a file system (actually quite a few) in sync across two
systems for DR purposes, but I am encountering something that I find strange.
Maybe its not strange, and I just don''t understand - but I will pose to
you fine people to help answer my question. This is all scripted, but I have
pulled out the relevant commands for your reference:

I have a file system on localnode and I create a snapshot call
"NMINUS1" which I then send to my remotenode.

zfs snapshot GT/test at NMINUS1
zfs send GT/test at NMINUS1 | ssh remotenode zfs receive GT/test at NMINUS1

This works properly, I then get the mountpoint property of the filesystem on the
localnode and using that, set it to the same on the remote node:

$mp = zfs get -Ho value mountpoint GT/test
ssh remotenode zfs set mountpoint=$mp GT/test

Again, works fine and this completes my inital setup.
>From that point onwards, I want to send an incremental snapshot on a, say,
nightly basis. So I create a new snapshot (NSNAP), send that across, and then
remove the old snap and rename the new to NMINUS1 ... so
zfs snapshot GT/test at NSNAP
zfs send -i NMINUS1 GT/test at NSNAP | ssh remotenode zfs receive GT/test

-- On both nodes
zfs destroy GT/test at NMINUS1
zfs rename GT/test at NSNAP GT/test at NMINUS1

Now everything works fine unless I perform a simple ''ls'' on
the filesystem on the remote node. On the local node I can modify the contents
of GT/test at any time, add or remove files, etc. and when I send the
incremental snapshot to the remote node, it completes properly, and I can do
this as many times as I want, but as soon as I issue that

# ls /GT/test

on the remote node, the next time I try to send an incremental snapshot I get
the following error:

# zfs send -i NMINUS1 GT/test at NSNAP | ssh remotenode zfs receive GT/test

cannot receive incremental stream: destination GT/ahg has been modified
since most recent snapshot

Other than modifying possibly access time - what has been change in the snapshot
that causes this problem?? One item of note (or not) one system is SPARC one is
AMD based.

Thanks for any ideas.
-- 
This message posted from opensolaris.org

Tony,

I believe you want to use "zfs recv -F" to force a rollback on the 
receiving side.

I''m wondering if your ls is updating the atime somewhere, which would 
indeed be a change...

-Greg

Greg Mason wrote:
> Tony,
> 
> I believe you want to use "zfs recv -F" to force a rollback on
the
> receiving side.
> 
> I''m wondering if your ls is updating the atime somewhere, which
would
> indeed be a change...
Yes.

If you want to have a look around it, cd into the last snapshot and look 
around in there instead, where you can''t modify anything.

-- 
Andrew

Thanks ... the -F works perfectly, and provides a further benefit in that the
client can mess with the file system as much as they want for testing purposes,
but when it comes time to ensure it is synchronized each night, it will revert
back to the previous state.

Thanks
-Tony
-- 
This message posted from opensolaris.org

Tony,

On Wed, Feb 04, 2009 at 09:10:26AM -0800, Tony Galway
wrote:
> Thanks ... the -F works perfectly, and provides a further benefit in that
the client can mess with the file system as much as they want for testing
purposes, but when it comes time to ensure it is synchronized each night, it
will revert back to the previous state.
Another option would be to turn off atime if you are sure that you are not
planing to modify anything on the destination box.

But, like you mentioned above if you allow users to mess around with the FS
then -F seems to be a better option.

Regards,
Sanjeev
> 
> Thanks
> -Tony
> -- 
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss