On Mon, May 15, 2017 at 12:02:48PM -0400, J. Bruce Fields wrote: > On Mon, May 15, 2017 at 03:43:06PM +0100, Stefan Hajnoczi wrote: > > On Fri, May 12, 2017 at 01:00:47PM -0400, Chuck Lever wrote: > > > > > > > On May 12, 2017, at 11:01 AM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > > > Actually, this might be a use case for re-exporting NFS. If the host > > > > could re-export a NFS mount to the guests, then you don't necessarily > > > > need a clustered filesystem. > > > > > > > > OTOH, this would not solve the problem of migrating locks, which is not > > > > really easy to support in the current state model for NFSv4.x. > > > > > > Some alternatives: > > > > > > - Make the local NFS server's exports read-only, NFSv3 > > > only, and do not support locking. Ensure that the > > > filehandles and namespace are the same on every NFS > > > server. > > > > > > - As Trond suggested, all the local NFS servers accessed > > > via AF_SOCK should re-export NFS filesystems that > > > are located elsewhere and are visible everywhere. > > > > > > - Ensure there is an accompanying NFSv4 FS migration event > > > that moves the client's files (and possibly its open and > > > lock state) from the local NFS server to the destination > > > NFS server concurrent with the live migration. > > > > > > If the client is aware of the FS migration, it will expect > > > the filehandles to be the same, but it can reconstruct > > > the open and lock state on the destination server (if that > > > server allows GRACEful recovery for that client). > > > > > > This is possible in the protocol and implemented in the > > > Linux NFS client, but none of it is implemented in the > > > Linux NFS server. > > > > Great, thanks for the pointers everyone. > > > > It's clear to me that AF_VSOCK won't get NFS migration for free. > > Initially live migration will not be supported. > > > > Re-exporting sounds interesting - perhaps the new host could re-export > > the old host's file systems. I'll look into the spec and code. > > I've since forgotten the limitations of the nfs reexport series. > > Locking (lock recovery, specifically) seems like the biggest problem to > solve to improve clustered nfs service; without that, it might actually > be easier than reexporting, I don't know. If there's a use case for > clustered nfs service that doesn't support file locking, maybe we should > look into it. I suspect many guests will have a dedicated/private export. The guest will be the only client accessing its export. This could simplify the locking issues. That said, it would be nice to support full clustered operation. Stefan
Attachment:
signature.asc
Description: PGP signature
