Subject: RE: [nfsv4] Global namespace for v4.1?

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 21 Dec 2003 17:53:30 -0800

Rob Thurlow wrote:
> I'm very late in this thread, for which I apologize.
> I hope I have some content worth the wait :-)

> First off, I should remind folks about my I-D:
> http://www.ietf.org/internet-drafts/draft-thurlow-nfsv4-namespace-00.txt

> This will expire soon, and I want to update it in the
> New Year to get some more stuff into it.  To that end,
> please either send me comments on changes or let me
> know if you want to own a chunk of it and become a
> co-author.  

My comment is that the draft should discuss the relationship
between a REFERRAL error and a MOVED error.  How, is the 
handling similar and different?

> Or, if it bugs you enough, go ahead and
> write another draft.  In the next spin, I'd like to
> focus on clearly stating options (without making any
> decisions yet) for finding the root node, and for
> Internet-wide vs. enterprise-wide scope.  The
> requirements could be beefed up, too.

> Next, what should we be doing?  I agree that we need
> to Just Get On With It, and based on that feeling, I
> showed up at the last Bakeoff with client code to
> try to deal with NFS4ERR_MOVED, and was able to take
> the client a lot farther and also get a swag at the
> server side.  I was able to test with Dave, but
> despite trading bugs for awhile, we didn't get so
> far as having a successful migration event.  

I think we'll get farther at Cthon.  One other thing to
note is that a referral event is a basically a subset of a 
migration event and should be easier to get going.  Famous
last words, I know.

> My code
> is dumb as a rock - it is smart enough to parse a
> dotted-quad format IPv4 string, and doesn't try to
> do an upcall yet - that needs to be done.

I'm thinking that in an environment where you have a mount
command getting the initial filehandle, you would process
referrals in that environment, so you might not need 
upcalls to deal with hostnames.
  
> I know
> I intend to show up with this code again, hopefully
> in better shape, and would certainly like to see
> other people in the migrate-a-thon as well (sounds
> like Trond has something more that at the Bakeoff? :-)

> However, while we mess with these prototypes, I do
> think we need to keep half a lobe on what we should
> try to get to in the future.  fs_locations is a start,
> but it's not enough, or even specified clearly enough
> yet.

> In the short term, we can leave OTW encoding alone
> and permit some spec reinterpretations.  Dave has
> talked about his fsid issue, and I guess there's not
> closure on whether that is strictly necessary, but if
> it's not harmful, 

It (fsid) is not strictly necessary.  fs_root provides the
necessary information, although I find it an annoying way to
do it.  I'll get over it, though (eventually).

Providing it is not harmful, should be easy for the server 
to do and is allowed by the spec.

Clients may request fsid but they need to be prepared for it 
not to be returned with MOVED, and so they need to be able
to use fs_root to determine where the fs starts.

I think the spec as written covers all this, even though it
seems a little unclear at first.

> it'd be nice for the server to return
> these if asked.  

I intend to return this at Cthon, but maybe I should have a
switch not to do so, to make sure clients can work with
servers that only return the minimum required by the spec.

> I have another issue - as David had
> mentioned, the spec is actually only set up for migration
> of something you've already been using - you can't
> get a filehandle for a filesystem that's moved before
> you got there, because the only ops you're supposed
> to be able to use are PUTFH and GETATTR.  So we should
> permit LOOKUP as well in practice.

I don't see the problem.  I don't see any problem doing a 
LOOKUP in an fs (in this case the pseudo-fs) that crosses
into an absent or migrated fs.  It should not and won't
give you MOVED on that because the fh you are presenting
is in a present fs.  Only when you use the new current file
handle (in an absent fs) do you need the spec to make
exceptions for your reference to the absent fs.  No
exception should be made for LOOKUP within an absent fs
because the server will typically not have access to
the contents of directories within the absent fs.

> Beyond that, we need more work.  We should not have to
> guess what type of thing is encoded in fs_locations,
> as we now do - we should have a tag to tell hostnames
> from IPv4 addresses from IPv6 addresses, and whatever
> we come up with should be extensible to other formats.

Although I agree that what we have isn't ideal, this 
doesn't seem like a very pressing issue.  We should certainly
address this when we and if we do a major revision of fs_locations
but I think it shouldn't stop us from getting migration and
referral into active use.
  
> Also, I feel a need for metadata about the locations -
> is this location read-only or will it accept writes?
> It's been argued here that the client can find that
> out if it needs to know, but that's ugly.  

I agree this is ugly.

> I think
> David pointed to a desire to know that some locations
> were alternate paths to the same storage, and that's
> another thing we could do if we defined some kind of
> attribute (say, an opaque global ID tied to the
> underlying storage).

I'm a little bit put off by the almost metaphysical 
implications of "the same storage".  I think we can focus
on the client-perceivable relationships among the elements
of the fs_locations: A write on one locations will or won't
be immediately visible on the other, the file handles are 
or are not the same, locks on one do or do not conflict 
with locks on the other, etc.

> I think prototyping will permit us to do a good job
> at making a wish list for the future, and that that
> wish list should become an RFC as soon as it can be
> done.  If that's before V4.1, cool - we can consider
> it.  It's not wasted effort if not, though.  (And
> if you wonder about the V4.1 timeline, please do
> ask your friendly WG chairs :-)

I've asked and I never get a clear answer, but my impression
is that if you are talking about a wish list which will only
be done after some prototyping in the new year, your wishes
are unlikely to be satisfied in v4.1

I think that what is in RFC3530, while not perfect, gives you
the basic stuff you need.

> Some other random notes:
> 
> - David's taxonomy of client and server capabilities
>    was useful.  I tend to not see why folks like Brent
>    and David want the client to consult the namespace
>    repository directly - can someone tell me why that's
>    a better architecture at all?  I know it's another
>    step to have the server involved, but it's only
>    another cache, and I think we can do that.  I am
>    obviously sympathetic to the idea that if we have
>    to implement migration anyway, we should use that
>    mechanism to do namespace referrals as well, and
>    I don't recognize a trigger that says that that's
>    not good enough for a smarter client.

Don't expect me to argue with you.

> - We haven't talked about management enough, and I
>    don't think that's healthy.  Should we have one
>    master repository of all this stuff, or should it
>    be decentralized as a hierarchy of namespaces?
>    Who should get to make changes and how should
>    they do that?  What standard protocols make sense
>    here?  It's a big area.

Exactly.  The fact that it is a big area means that we 
should get started soon, since dealing with the questions
you mention is liable to take a while.  This is why I
feel very strongly that we should take advantage of the
fact that RFC3530 gives us migration+referrals for the
price of migration, and allow people to get the benefits
of local site-wide or even enterprise-wide namespaces, 
with clients set up and deployed so that they can take 
advantage of the ongoing evolution in namespace construction,
as it proceeds.

> I hope folks have a great Christmas break - mine
> starts tomorrow, so I won't see further traffic
> for awhile.

Are you sure you can live without it? :-)

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 Dec 2003 02:11:25 -0800

> > out if it needs to know, but that's ugly.  

But the referring server can't be guaranteed to always know.

Which servers can be authoritative always about such info anyways, the
ones issuing the referrals?  or the ones hosting the filesystems
referred to?

The answer is obvious.  The curret model reflects this truth, so how can
it be ugly?

[...]
> the basic stuff you need.

I agree; enough to get started and get a lot of good functionality
anyways.

> advantage of the ongoing evolution in namespace construction,

Yes.

Cheers,

Nico
--