Subject: Re: [nfsv4] [FedFS] Junctions in file system snapshots

From: Robert Thurlow <[email-masked]>
Date: Thu, 07 Jan 2010 10:26:48 -0700

[email-masked] wrote:

> What is the expectation for the client experience when they encounter a 
> junction in a snapshot of a fileset snapshot?  That is, the client is 
> traversing the point in time view of what the fileset looked like at 
> some point in the past.   That fileset happened to contain a junction 
> when it was created.  The user decides to traverse through that junction 
> – what do we expect will happen?

I was quite surprised by how much discussion this question
raised, and the level of complexity people were willing
to bring to it.

First, if you are accessing a snapshot from a client, you
the user need to be involved, since the NFSv4.x protocol
does not have any inherent understanding of snapshots and
different vendors make these available in different ways
(if they make them available at all).  So the user should
be engaged here.

Second, a snapshot created on the server should certainly
store the FSN as it existed at the time the snapshot was
taken, which means that the server should pick up the FSN
and look up the current FSLs in the NSDB.  Anything else
would be a surprise.  This is also true of backup and
restore situations.

I also think that this highlights that it is a Good Thing
to make sure your FSNs tend to be stuff that's useful for
a long time, because pointers to them can live ~forever.

I think this is a good thing.  The value of the UUIDs we
use for FSNs is that they are interfaces behind which
implementation can change.  If you want to change from a
single Linux box to several redundant higher-end servers,
the clients will not really notice anything except the
better service.  I don't think there's a need to create
a mystical world for the client where all files would
be the same as they were at a specific point in time.

Now, this does mean that you have to understand how the
system works to use it well.  If you create an FSN for
the gcc compiler and point it to gcc 2.2, and then update
to gcc 3.1, you may not like the results.  You may want
to create versioned things, so that there's an FSN for
gcc 2.2 and another for gcc 3.1.  Stuff like HR documents
would be different - you would likely just add and change
stuff as needed and not version it.

That means the only option that makes sense is this one:

> b) They end up in the current, production, copy of the target fileset – 
> assumes the target fileset still exists.

The other options are odd:

> a) Nothing – the junction appears and behaves as an empty directory.

This is gratuitiously unhelpful, isn't it?

> c) They end up in a snapshot of the target fileset that represents the 
> same point in time as the one they’ve just come from – assumption that 
> such a snapshot exists.

This is impossible without NFSv4.x and FedFS being able to
talk about snapshots, IMO.  Imagine doing this when the
servers are not from the same vendor.

I don't in any way believe it makes sense to try to back in
awareness of snapshot naming and semantics into FedFS when we
did not choose to do so in NFSv4.x.

Rob T