On Tue, Sep 19, 2017 at 05:09:25PM -0400, Chuck Lever wrote: > > > On Sep 19, 2017, at 4:42 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > On Tue, Sep 19, 2017 at 03:56:50PM -0400, Chuck Lever wrote: > >> A proof of concept is nice, but it isn't sufficient for merging > >> NFS/VSOCK into upstream Linux. Unlike Ceph, NFS is an Internet > >> standard. We can't introduce changes as we please and expect > >> the rest of the world to follow us. > >> > >> I know the Ganesha folks chafe at this requirement, because > >> standardization progress can sometimes be measured in geological > >> time units. > > > > It doesn't need to be--I think we're only asking for a few pages here, > > and nothing especially complicated (at the protocol level). > > That would define RPC over VSOCK. I would like to see a problem > statement here, and we'd want to find a normative reference defining > VSOCK addressing. Does one exist? > > My sense is that NFS on VSOCK would need more. The proof of concept > I'm aware of drops a lot of functionality (for example, NFSv2/3 is > excluded, and so is RPCSEC GSS and NFSv4.0 backchannel) to make NFS > work on this transport. Interoperability would require that list > be written somewhere. I don't think they need to support NFSv2/3 or RPCSEC_GSS, but it could be worth a little text to explain why not, if they don't. > We also need to deal with filehandles and lock state during guest > live migration. That sounds like a separate issue independent of transport. I've been assuming there's still some use to them in an implementation that doesn't support migration at first. If not it's a bigger project. --b. > > That feels like more than a few pages to me. > > > > That > > shouldn't take so long. (Not to be published as an RFC, necessarily, > > but to get far enough along that we can be pretty certain it won't need > > incompatible changes.) > > > -- > Chuck Lever -- 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
