Thank you Jonathan.  The point of this exercise is . In ZFS, there is no
.snapshot directory.  Instead, there is a .zfs/snapshot directory, which
only exists at the root of the filesystem.  In order to access snaps in ZFS,
you have to go up to the root, into .zfs/snapshot, and tunnel your way back
down to the level of PWD.

 

While I'm talking with some ZFS folks, describing the netapp style .snapshot
directory which exists everywhere, there's some confusion about how it
actually works.  Because the real directory structure doesn't always map
directly to the snapshot directory structure.  So when we "mv somedir
somenewname" then what happens to the .snapshot directories?  If you rename
a directory, do all the snapshots of the children disappear?  In order to
access such snaps, do you have to go to the unchanged parent, and then
tunnel down?  Or is it smart enough to recognize that was just a "rename"
operation, and therefore all the children snaps still exist as you would
hope, in addition to the parent directory .snapshot having another copy?

 

Your answer below very nearly answers it, but it leaves me with one point of
confusion remaining.

 

When you find a/.snapshot, I am expecting the directory structure and file
to look like it did at the time of the snapshot.  Where is d.txt?  It's
conspicuously missing.  I don't get that.  Is there any possibility you just
accidentally made a mistake while pasting?

 

I don't think so.  Since it explicitly says that a/.snapshot/b/c exists, and
then it says a/.snapshot/b/c is not a directory.  It seems as though the
snapshot under a/.snapshot is no longer a representation of how the
filesystem looked at the time of the snapshot.  It appears that the snapshot
was moved along with the directory, and it's no longer accessible inside of
a/.snapshot.    (!?!?)  

 

Until now, I always believed that .snapshot contained a read-only picture of
the way the filesystem was at the time of the snapshot.  Based on what
you've got below . That appears to be a false belief.

 

What exactly, *is* a/.snapshot/vol0_deleteme/b/c in this case?  Or just b?
One of those must be an object of some kind, which isn't a directory.  I'm
honestly very surprised it doesn't work.

 

 

 

From: Jonathan Nicol [mailto:[email protected]] 
Sent: Thursday, April 22, 2010 11:51 PM
To: Edward Ned Harvey
Cc: [email protected]
Subject: Re: [lopsa-tech] Anybody with a netapp?

 

Hi Edward:

 

# mkdir a

# mkdir a/b

# mkdir a/b/c

# echo "whee" > a/b/c/d.txt

 

> snap create vol0 vol0_deleteme

 

# mv a/b a/e

# ls a/e/c/.snapshot

vol0_deleteme

# ls a/e/c/.snapshot/vol0_deleteme/

d.txt

# find a/.snapshot

a/.snapshot

a/.snapshot/vol0_deleteme

a/.snapshot/vol0_deleteme/b

a/.snapshot/vol0_deleteme/b/c

find: a/.snapshot/vol0_deleteme/b/c: Not a directory

# find a/e/c/.snapshot

a/e/c/.snapshot

a/e/c/.snapshot/vol0_deleteme

a/e/c/.snapshot/vol0_deleteme/d.txt

 

Not sure exactly what you're getting at, but hope this helps :)

 

 

Jonathan

 

 

On Apr 22, 2010, at 8:29 PM, Edward Ned Harvey wrote:





I've been having some discussions about snapshot behavior with ZFS as
compared to snapshot behavior with Netapp.  And there's this question, which
I don't know the answer of . because I don't have any netapp anymore .

 

Anyone with a netapp care to answer this?

 

      mkdir a

mkdir a/b

mkdir a/b/c

      echo "whee" > a/b/c/d.txt

      [snapshot is taken]

      mv a/b /a/e

 

What are now the contents of a/e/c/.snapshot ?

Maybe the results of "find a/.snapshot" and "find a/e/c/.snapshot" would be
a good answer to this question.

 

Thanks, anyone.

_______________________________________________
Tech mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/

 

_______________________________________________
Tech mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to