From: Vivek Goyal <vgoyal@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Jason Wang <jasowang@redhat.com>,
virtualization@lists.linux-foundation.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
virtio-fs@redhat.com, Stefan Hajnoczi <stefanha@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v3 00/13] virtio-fs: shared file system for virtual machines
Date: Tue, 3 Sep 2019 10:18:51 -0400 [thread overview]
Message-ID: <20190903141851.GC10983@redhat.com> (raw)
In-Reply-To: <20190903101001-mutt-send-email-mst@kernel.org>
On Tue, Sep 03, 2019 at 10:12:16AM -0400, Michael S. Tsirkin wrote:
> On Tue, Sep 03, 2019 at 10:07:52AM -0400, Vivek Goyal wrote:
> > On Tue, Sep 03, 2019 at 04:31:38AM -0400, Michael S. Tsirkin wrote:
> >
> > [..]
> > > + /* TODO lock */
> > > give me pause.
> > >
> > > Cleanup generally seems broken to me - what pauses the FS
> >
> > I am looking into device removal aspect of it now. Thinking of adding
> > a reference count to virtiofs device and possibly also a bit flag to
> > indicate if device is still alive. That way, we should be able to cleanup
> > device more gracefully.
>
> Generally, the way to cleanup things is to first disconnect device from
> linux so linux won't send new requests, wait for old ones to finish.
I was thinking of following.
- Set a flag on device to indicate device is dead and not queue new
requests. Device removal call can set this flag.
- Return errors when fs code tries to queue new request.
- Drop device creation reference in device removal path. If device is
mounted at the time of removal, that reference will still be active
and device state will not be cleaned up in kernel yet.
- User unmounts the fs, and that will drop last reference to device and
will lead to cleanup of in kernel state of the device.
Does that sound reasonable.
Vivek
next prev parent reply other threads:[~2019-09-03 14:19 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 17:37 [PATCH v3 00/13] virtio-fs: shared file system for virtual machines Vivek Goyal
2019-08-21 17:37 ` [PATCH 01/13] fuse: delete dentry if timeout is zero Vivek Goyal
2019-08-21 17:37 ` [PATCH 02/13] fuse: Use default_file_splice_read for direct IO Vivek Goyal
2019-08-28 7:45 ` Miklos Szeredi
2019-08-28 12:27 ` Vivek Goyal
2019-08-21 17:37 ` [PATCH 03/13] fuse: export fuse_end_request() Vivek Goyal
2019-08-21 17:37 ` [PATCH 04/13] fuse: export fuse_len_args() Vivek Goyal
2019-08-21 17:37 ` [PATCH 05/13] fuse: Export fuse_send_init_request() Vivek Goyal
2019-08-21 17:37 ` [PATCH 06/13] fuse: export fuse_get_unique() Vivek Goyal
2019-08-21 17:37 ` [PATCH 07/13] Export fuse_dequeue_forget() function Vivek Goyal
2019-08-21 17:37 ` [PATCH 08/13] fuse: extract fuse_fill_super_common() Vivek Goyal
2019-08-21 17:37 ` [PATCH 09/13] fuse: add fuse_iqueue_ops callbacks Vivek Goyal
2019-08-21 17:37 ` [PATCH 10/13] fuse: Separate fuse device allocation and installation in fuse_conn Vivek Goyal
2019-08-21 17:37 ` [PATCH 11/13] virtio_fs: add skeleton virtio_fs.ko module Vivek Goyal
2019-08-21 17:37 ` [PATCH 12/13] virtio-fs: Do not provide abort interface in fusectl Vivek Goyal
2019-08-21 17:37 ` [PATCH 13/13] init/do_mounts.c: add virtio_fs root fs support Vivek Goyal
2019-08-29 9:28 ` [PATCH v3 00/13] virtio-fs: shared file system for virtual machines Miklos Szeredi
2019-08-29 11:58 ` Vivek Goyal
2019-08-29 12:35 ` Stefan Hajnoczi
2019-08-29 13:29 ` Vivek Goyal
2019-08-29 13:41 ` Miklos Szeredi
2019-08-29 14:31 ` Vivek Goyal
2019-08-29 14:47 ` Miklos Szeredi
2019-08-29 16:01 ` Vivek Goyal
2019-08-31 5:46 ` Miklos Szeredi
2019-09-03 8:05 ` Miklos Szeredi
2019-09-03 8:31 ` Michael S. Tsirkin
2019-09-03 9:17 ` Miklos Szeredi
2019-09-04 15:54 ` Stefan Hajnoczi
2019-09-03 14:07 ` Vivek Goyal
2019-09-03 14:12 ` Michael S. Tsirkin
2019-09-03 14:18 ` Vivek Goyal [this message]
2019-09-03 17:15 ` Michael S. Tsirkin
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=20190903141851.GC10983@redhat.com \
--to=vgoyal@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jasowang@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mst@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-fs@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
/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).