From: Mike Eisler (mike@eisler.com)
Date: 12/19/02-02:17:47 PM Z
Message-ID: <3E02296B.3040007@eisler.com>
Date: Thu, 19 Dec 2002 12:17:47 -0800
From: Mike Eisler <mike@eisler.com>
Subject: Re: Comments on draft-ietf-nfsv4-repl-mig-proto-00.txt
>
>
>
>>I realize that some of the things I'm observing are a
>>result of this being a strawman, but I can also see us
>>getting bogged down in specifying what is effectively a
>>layer in the protocol stack, when we already have one, ONC
>>RPC, to use today. Time is of the essence.
>>
>
>So let's open this up for discussion. Suppose we make at
>least a first attempt (in the Connectathon 2003 timeframe)
>with an RPC-based protocol, based on this strawman. Does
>that make sense for others who might want to try this at
>C-thon 2003? I can certainly be convinced, because I have
>less time for prototyping than I'd initially hoped. What
>about some of the other design team folks?
>
Cool. Let's cover the security thing and make
krb5, krb5i, krb5p MANDATORY too.
Speaking of Connectathon, in addition to testing
the strawman, it would be nice to do some NFSv4 client
testing to see if NFSv4 referrals (fs_locationed,
NFS4ERR_MOVED, etc.) actually work. This doesn't
necessarily require a complete or partial implementations
of the strawman repl-mig protocol.
>
>>In section 2.5 (and section 7), why is the nfsace4 type
>>imported from nfsv4? If the other attribute types aren't
>>importanted, there should be no need for the ace type.
>>
>
>I brought in fattr4's as well; I wanted to use them verbatim
>when we're working with NFSv4 metadata.
>
There are dozens of attribues other than nfsace4, and they aren't
in the strawman, It should be sufficient to refer to the types
coming from nfsv4, rather that having duplicates in the
repl-mig protocol's .x file.
>
>
>>In section 4.4, regarding the RM_UTF8NAMES capability flag,
>>why doesn't the nfsv4 migration protocol assume UTF8 file names?
>>So why does this bit need to exist?
>>
>
>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.
>
The target might be storing just US-ASCII, or US-ASCII
plus the 8 bit Euro character set, or the entire
16-bit only Unicode. And there are probably intermediate degrees
of capability. So in general I don't know how this information gets
conveyed.
I think it is best to use the existing NFSv4 practice for letting the target
reject names it can't convey, and thus give the source the ooption of
mapping the names to simpler characters.
>
>
>>Regarding the RM_FHPRESERVE capability, unless the source
>>and target know the fh format, this capability seems useless.
>>Since NFSv4 defines file handles as opaque, the capability is
>>indeed useless, unless source and target know they have compatible
>>file handles. My suggestion:
>>
>> Include in the OPEN_SESSION_NEW arguments a field
>> of type utf8str_cis (from the nfsv4 spec) which is
>> a dns domain name that serves as an
>> "implementation" identifier to uniquely and
>> unambiguously identifies the file handle format. If
>> a particular implementer has multiple fh formats
>> (e.g. because it has both big endian and little
>> endian platform support), then it can use multiple
>> domain names or subdomain names. If the source and
>> target have different domain names, it is still
>> possible the target understands the source's file
>> handle format, and it can still turn on the
>> PRESERVE capability.
>>
>
>Yes, this was underspecified and you have pointed towards
>a way out. I had also thought (fantasized?) about trying
>to encode the way the filehandle was put together - i.e.,
>these bytes are invariant in this filesystem, these bits
>represent the specific file, and these bits represent the
>share point. The biggest problem is that this assumes a
>filehandle will consist of all of these parts, which is
>probably not sufficiently general.
>
Right, designing a file handle description lanugage is a fantasy.
>
>
>>Does RM_FHPRESERVE also imply preservation of fileid?
>>
>
>For domains where it is useful, it probably will, but I
>don't know if it should be specified so.
>
If there is no implication, we may need RM_FILEID
since there's prose in the v4 spec that talks about leveraging
fileid to tell if file handles are unique.
>
>>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.
>
That could be bad, just as we agree that it would
be bad if overall system forced clients to re-establish lock state
on the target. Recall of the delegation can result in a flurry of
byte range lock requests (per delegation) getting synced
to the source, and then the target (via the transfer protocol).
That's just one example. I think SEND_DELEGATION_STATE should
be in; sources don't have to use it, and we could even make
it a negotiable capability.
>
>>In section 5.3 there is a RM_CIFS_ATTR type. Why is this
>>needed? This is the NFSv4 migration protocol, and in any
>>case, the set of NFSv4 attributes is rich enough to
>>encompass what Windows environments need.
>>
>
>That's there so that vendors that sell multi-protocol
>servers can express any CIFS attributes we can't encode
>with NFSv4, and to illustrate the intent that we're not
>supporting NFSv4 only, just NFSv4 first. If this is not
>useful, it can go, but I'd like to maintain support for
>alternate attribute "profiles" in the future.
>
We can encode any attrbute in NFSv4, just add a minor version.
Vendors that with multi-protocol servers are accomodated whether they
support NFSv4 or not, CIFS or not.
Otherwise, here's what we have:
- underspecified and/or opaque attributes that aren't in
control of IETF, or
- well specified attributes that are in the transfer
protocol, but not in the NFSv4 protocol, thereby denying
NFS users the capability to read these attributes.
>
>>In section 6.3, ABORT_SESSION overloading ABORT_SESSION to
>>be both the confirmation from the target, or an initiated
>>message from the target is going to make implementation
>>complex. Just have two different message types, or better
>>yet, RPCs. (and make CLOSE_SESSION an RPC as well).
>>
>
>How does the destination perform an abort? Do we have to
>define that the source implement a server side to receive it?
>
We have to allow for bidirectional RPC on the same connection. This
doesn't seem like it should be hard to implement, even in kernels.
>
>
>>Section 6.2 implies that if a session is explicitly aborted
>>via ABORT_SESSION, it can later be resumed. It seems to me
>>that there ought to be an operation to allow the source to
>>tell the target that the session will not be resumed, and
>>another operation to tell the source that the target is
>>aborting and it will not maintain the previous state:
>>resumption is futile. Maybe this can be done with specific
>>error codes, but specific operations seems less error
>>prone.
>>
>
>I guess I expect the abort stuff to be in a crisis handler,
>where a lot of computation is not welcome. The implementation
>could advertise if it can do restart or not at connection
>time, which might accomplish enough here - would that work?
>
There are cases where the target and server will be able to restart or not,
and it may not know when the session is created (e.g. the source or target's
disk has crashed, or ENOSPC has occurred on the target).
>
>
>>In section 7 and else where, what are the definitions of the
>>various compression types? Do the compression types only
>>apply to the data field of the SEND_FILE_DATA operation.
>>
>
>Underspecified again, and yes.
>
Also, there are likely intellectual property issues around some of those
compression types. We want to tread carefully here; optional,
negotiable compression is goodness since it is possible
(probable?) ipr issues won't let us make
any mandatory.
>
>>- Can there be multiple sessions per TCP connection?
>>
>
>I'd prefer separate TCP connections for separate sessions.
>
Works for me, just needs to be stated,
>
>
>>- Presumably this protocol requires an IETF approved
>> congestion management transport, so TCP is the
>> required transport.
>>
>
>Yes; I thought I had specified that somewhere.
>
Thisi is the only mention of TCP I found,
but I think adopting the Area Director
approved language from the nfsv4 spec is a
good thing to do now:
As discussed in [DESIGN], this protocol draft will not use
RPC [RFC1831] but will use XDR [RFC1832] formatted messages over TCP
to maximize efficiency.
-mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:43 AM Z CST