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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.