From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Chuck Lever'" <chuck.lever@oracle.com>,
"'J. Bruce Fields'" <bfields@fieldses.org>
Cc: "'Daniel P. Berrange'" <berrange@redhat.com>,
"'Stefan Hajnoczi'" <stefanha@redhat.com>,
"'Steve Dickson'" <SteveD@redhat.com>,
"'Linux NFS Mailing List'" <linux-nfs@vger.kernel.org>,
"'Matt Benjamin'" <mbenjami@redhat.com>,
"'Jeff Layton'" <jlayton@redhat.com>
Subject: RE: [PATCH nfs-utils v3 00/14] add NFS over AF_VSOCK support
Date: Wed, 20 Sep 2017 08:25:38 -0700 [thread overview]
Message-ID: <015601d33224$b7770b40$266521c0$@mindspring.com> (raw)
In-Reply-To: <202BF722-77BC-4EF2-BD75-9AA42CBF4A94@oracle.com>
> > On Sep 20, 2017, at 10:45 AM, J. Bruce Fields <bfields@fieldses.org>
wrote:
> >
> > On Wed, Sep 20, 2017 at 10:40:45AM -0400, Chuck Lever wrote:
> >> File handles suddenly change and lock state vanishes after a live
> >> migration event, both of which would be catastrophic for hypervisor
> >> mount points.
> >
> > They're talking about a Ganesha/Ceph backend. It should be able to
> > preserve filehandles.
>
> That's only one possible implementation. I'm thinking in terms of what
needs
> to be documented for interoperability purposes.
It seems like live migration pretty much requires a back end that will
preserve file handles.
> > Lock migration will require server-side implementation work but not
> > protocol changes that I'm aware of.
> >
> > It could be a lot of implementation work, though.
>
> Agreed.
I think the lock migration can be handled the way we handle state migration
in an HA environment - where we treat it as a server reboot to the client
(so SM_NOTIFY to v3 clients, the various errors v4 uses to signal server
reboot, in either case, the client will initiate lock reclaim).
Frank
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
next prev parent reply other threads:[~2017-09-20 17:39 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-13 10:26 [PATCH nfs-utils v3 00/14] add NFS over AF_VSOCK support Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 01/14] mount: don't use IPPROTO_UDP for address resolution Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 02/14] nfs-utils: add vsock.h Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 03/14] nfs-utils: add AF_VSOCK support to sockaddr.h Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 04/14] mount: present AF_VSOCK addresses Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 05/14] mount: accept AF_VSOCK in nfs_verify_family() Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 06/14] mount: generate AF_VSOCK clientaddr Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 07/14] getport: recognize "vsock" netid Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 08/14] mount: AF_VSOCK address parsing Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 09/14] exportfs: introduce host_freeaddrinfo() Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 10/14] exportfs: add AF_VSOCK address parsing and printing Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 11/14] exportfs: add AF_VSOCK support to set_addrlist() Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 12/14] exportfs: add support for "vsock:" exports(5) syntax Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 13/14] nfsd: add --vsock (-v) option to nfsd Stefan Hajnoczi
2017-09-13 10:26 ` [PATCH nfs-utils v3 14/14] tests: add "vsock:" exports(5) test case Stefan Hajnoczi
2017-09-13 16:21 ` [PATCH nfs-utils v3 00/14] add NFS over AF_VSOCK support Christoph Hellwig
2017-09-13 18:18 ` [nfsv4] " David Noveck
2017-09-13 18:21 ` Chuck Lever
2017-09-15 11:52 ` Stefan Hajnoczi
2017-09-13 22:39 ` NeilBrown
2017-09-14 15:39 ` Steve Dickson
2017-09-14 15:55 ` Steve Dickson
2017-09-14 17:37 ` J . Bruce Fields
2017-09-15 11:07 ` Jeff Layton
2017-09-15 15:17 ` J . Bruce Fields
2017-09-15 23:29 ` NeilBrown
2017-09-16 14:55 ` J . Bruce Fields
2017-09-15 13:12 ` Stefan Hajnoczi
2017-09-15 13:31 ` J . Bruce Fields
2017-09-15 13:59 ` Chuck Lever
2017-09-15 16:42 ` J. Bruce Fields
2017-09-16 15:55 ` Chuck Lever
2017-09-18 18:09 ` Stefan Hajnoczi
2017-09-19 9:31 ` Daniel P. Berrange
2017-09-19 14:35 ` Chuck Lever
2017-09-19 15:10 ` Daniel P. Berrange
2017-09-19 15:48 ` Chuck Lever
2017-09-19 16:44 ` Daniel P. Berrange
2017-09-19 17:24 ` J. Bruce Fields
2017-09-21 17:00 ` Stefan Hajnoczi
2017-09-22 9:55 ` Steven Whitehouse
2017-09-22 11:32 ` Jeff Layton
2017-09-22 12:08 ` Matt Benjamin
2017-09-22 12:26 ` Jeff Layton
2017-09-22 15:28 ` Stefan Hajnoczi
2017-09-22 16:23 ` Daniel P. Berrange
2017-09-22 18:31 ` Chuck Lever
2017-09-25 8:14 ` Daniel P. Berrange
2017-09-25 10:31 ` Chuck Lever
2017-09-22 11:43 ` Chuck Lever
2017-09-22 11:55 ` Daniel P. Berrange
2017-09-22 12:00 ` Chuck Lever
2017-09-22 12:10 ` Daniel P. Berrange
2017-09-22 19:14 ` J. Bruce Fields
2017-09-25 8:30 ` Daniel P. Berrange
2017-09-26 2:08 ` NeilBrown
2017-09-26 3:40 ` J. Bruce Fields
2017-09-26 10:56 ` Stefan Hajnoczi
2017-09-26 11:07 ` Daniel P. Berrange
2017-09-26 18:32 ` J. Bruce Fields
2017-09-27 0:45 ` NeilBrown
2017-09-27 13:05 ` Stefan Hajnoczi
2017-09-27 22:21 ` NeilBrown
2017-09-28 10:44 ` Stefan Hajnoczi
2017-09-27 13:35 ` J. Bruce Fields
2017-09-27 22:25 ` NeilBrown
2017-09-26 13:39 ` J. Bruce Fields
2017-09-26 13:42 ` J. Bruce Fields
2017-09-27 12:22 ` Stefan Hajnoczi
2017-09-27 13:46 ` J. Bruce Fields
2017-09-28 10:34 ` Stefan Hajnoczi
2017-09-19 17:37 ` Stefan Hajnoczi
2017-09-19 19:56 ` Chuck Lever
2017-09-19 20:42 ` J. Bruce Fields
2017-09-19 21:09 ` Chuck Lever
2017-09-20 13:16 ` J. Bruce Fields
2017-09-20 14:40 ` Chuck Lever
2017-09-20 14:45 ` J. Bruce Fields
2017-09-20 14:59 ` Chuck Lever
2017-09-20 15:25 ` Frank Filz [this message]
2017-09-20 18:17 ` Trond Myklebust
2017-09-20 18:34 ` bfields
2017-09-20 18:38 ` Trond Myklebust
2017-09-21 16:20 ` Stefan Hajnoczi
2017-09-20 14:58 ` Daniel P. Berrange
2017-09-20 16:39 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='015601d33224$b7770b40$266521c0$@mindspring.com' \
--to=ffilzlnx@mindspring.com \
--cc=SteveD@redhat.com \
--cc=berrange@redhat.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=mbenjami@redhat.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).