From: Robert Thurlow (Robert.Thurlow@eng.sun.com)
Date: 12/19/02-06:32:32 PM Z
Date: Thu, 19 Dec 2002 17:32:32 -0700 (MST) From: Robert Thurlow <Robert.Thurlow@eng.sun.com> Subject: RE: Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt Message-ID: <Roam.SIMC.2.0.6.1040344352.25428.thurlow@jurassic.eng> [RPC] > But regardless of the specific time-frame, I don't see the > point of doing throw-away work. It sounds to me like that > is what you are proposing. If we want the protocol not > to be RPC-based, then that's what we should work on. If > we do want RPC, and I think that is the better choice, then > let's do that. Okay, let's see what we get on the consensus call. It's looking good for that viewpoint :-) > > I brought in fattr4's as well; I wanted to use them verbatim > > when we're working with NFSv4 metadata. > > Interesting change control issue. V4 is going to have minor > versions which may add attributes and so taking the v4.0 > verbatim is not what we want. We should probably negotiate > the minor version level that the attributes should correspond > to. Good point. > > What I was thinking about here was to try to encode if > > the server supports arbitrarily complex UTF8 names, or > > if they will be mapped to something like simple ASCII. > > The hope was that the source server could know this > > early on and inform the admin that metadata might be > > impacted on this destination server. > > But that's soooooo inadequate. ... This is part of the server > semantics stuff that I was mentioning. That may take > a while, but at least I'll try to come up reasonably soon > with something for the character set issue. That would be great - thanks! > > > 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. [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? Rob T
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:43 AM Z CST