Subject: RE: Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 19 Dec 2002 16:49:04 -0800

> > > > In Section 5.1, Data transfer phase messages, shouldn't
> > > > there be a SEND_DELEGATION_STATE message as well?
> > > 
> > > Possibly helpful; I'd expected we'd recall delegations
> > > just before pushing the final set of changes, and not
> > > issue new delegations until completion.
> > 
> > This reminds me of another issue.  The locking state is
> > sent over but no stateid information.
> 
> I'd consider this an oversight; I've had brain aches in the
> past thinking about how we offer a grace period to clients
> using a single filesystem, and would prefer not to go there
> unless it's important.

The other horn of the dilemma is that if you pass over the 
stateid's, they might conflict.  In a single-vendor implementation,
the stateid's are big enough that we could somehow encode the server
of origin and then do some internal remapping.  Doing that in a
general way is possible but would require some work in the
v4 protocol.

I guess the alternative is to key off the fs context within
which the stateid's are used.  There is the assumption in the
protocol now that from each stateid, you can determine the
filehandle that goes with it, but if we changed the understanding
so that the fs associated with the current fh could be used
in determining what state the stateid *really* referred to,
I think it would work.  It is harder for the destination 
system to work with stateid's that he didn't generate (the
guy who generates them makes them so that they are easy to 
access his structures) but it isn't impossible.

> [attributes profiles]
> > Possibly but we pulled a lot of CIFS attributes into v4.
> > 
> > The big problem I have with the way you specified this
> > is precisely that a multiprotocol server cannot sent over
> > information including fs attributes for all protocols.
> > Having it being able to send over fs attributes to support
> > CIFS or attributes to support V4 is not going to support
> > multi-protocol.

> I guess I don't see what makes it just not work.  I guess
> I expected there to be CIFS-specific attributes we didn't
> include, and that there was going to be a need to be able
> to send them.  If the profile listed only the ones that
> we didn't define with V4, would that help?  If not, what
> is the problem you see?

The problem is you have a descriminated union and I can with
that descriminated union choose to send the v4 attributes or
I can send the CIFS attributes (to be defined).  However, if
I have a filesystem which supports V4 and CIFS access, it
would of necessity have for each file the union of the v4 and
CIFS attributes and with the protocol in the strawman I can't
send that union.