On Wed, Sep 20, 2017 at 09:16:41AM -0400, J. Bruce Fields wrote: > 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. FWIW, the current virtio-9p filesystem passthrough does not support migration and still has found usage in a number of scenarios where that limitation is not important. ClearContainers / libvirt sandbox are two which use 9p and don't care about migration. With this in mind, NFS-over-VSOCK would still be valuable even if the specification explicitly stated that live migration is not permitted. If there was a specified way of supporting live migration with good semantics of the guest FS, then that would open up NFS-over-VSOCK to a wider range of use cases. Migration would likely be quite important to OpenStack usage, since live migration is the way cloud providers typically upgrade virt hosts to newer releases of OpenStack software. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- 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
