On Wed, Feb 11, 2015 at 10:15:43AM -0500, Trond Myklebust wrote: > On Wed, Feb 11, 2015 at 9:54 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Wed, Feb 11, 2015 at 06:16:19AM -0800, Christoph Hellwig wrote: > >> On Wed, Feb 11, 2015 at 09:12:57AM -0500, J. Bruce Fields wrote: > >> > I think so. That's all optional--e.g. for READ_PLUS clients can > >> > determine server support using ERR_OP_NOTSUPP (or whatever it's called), > >> > and for attributes they can query the supported_attributes attribute. > >> > It's possible we'll never support everything in 4.2. > >> > >> The questions is if we need a useful subset of 4.2 to bother. > > > > Internally the virtualization people have been interested in ALLOCATE, > > SEEK, and security labels, so I'm assuming we've passed that sort of > > minimum "is there any benefit at all to turning this on" threshhold. > > ACK. There is client support for that functionality that hooks into > well established system calls, which means that applications can use > it now without much in the way of changes (if at all). > > >> I doubt we'll ever bother with ADBs for example, and the copy offload > >> might take a while to get everyting sorted. But exposting most > >> attributes and supporting READ_PLUS sounds like important enought to > >> implement before considering 4.2 ready. > > > > I agree there's a documentation and marketing problem: it would simplify > > communication with users if "this server supports 4.2" reliably meant > > support for some minimum list of features. Is that what you're thinking > > about? > > None of our NFSv4 versions are 100% feature complete. Our approach on > both the client and server has been to take the functionality that is > useful to us and implement that first. > For instance, NFSv4.1 is still missing RPCSEC_GSS on the callback > channel. I do want to implement that feature some day, but that > doesn't stop me from considering NFSv4.1 to be useful in the state it > is today. > > > Individual distros and other server vendors may make their own decisions > > here, so I don't know if we do much about that on our own. > > > > We could also add a little more data e.g. to /proc/self/mountstats to > > help figure out stuff like "why does copying a big file go so much > > faster on server X than server Y?". > > We already have that information. As we add new RPC calls on the > client, we add corresponding entries in /proc/self/mountstats. When > copy offload goes in, it will have its own entry there, and you will > see the usage counts being bumped whenever an application calls it. Oh, and looking now--I'd forgotten that we also support the supported-attributes bitmaps. Maybe that covers everything. Someone could also add a server-side interface for querying features like this if it seemed useful. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
