[zfs-discuss] 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/t...@nminus1 zfs send GT/t...@nminus1 | ssh remotenode zfs receive GT/t...@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/t...@nsnap zfs send -i NMINUS1 GT/t...@nsnap | ssh remotenode zfs receive GT/test -- On both nodes zfs destroy GT/t...@nminus1 zfs rename GT/t...@nsnap GT/t...@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/t...@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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Send Receive (and why does 'ls' modify a snapshot?)
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Send Receive (and why does 'ls' modify a snapshot?)
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Send Receive (and why does 'ls' modify a snapshot?)
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Send Receive (and why does 'ls' modify a snapshot?)
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@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
