On Fri, Sep 6, 2019 at 2:08 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > On Fri, Sep 06, 2019 at 01:52:41PM +0200, Miklos Szeredi wrote: > > On Fri, Sep 6, 2019 at 12:36 PM Stefan Hajnoczi <stefanha@xxxxxxxxxx> wrote: > > > > > > On Fri, Sep 06, 2019 at 10:15:14AM +0200, Miklos Szeredi wrote: > > > > On Thu, Sep 5, 2019 at 9:49 PM Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > > > > > > > > > > Hi, > > > > > > > > > > Michael Tsirkin pointed out issues w.r.t various locking related TODO > > > > > items and races w.r.t device removal. > > > > > > > > > > In this first round of cleanups, I have taken care of most pressing > > > > > issues. > > > > > > > > > > These patches apply on top of following. > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git#virtiofs-v4 > > > > > > > > > > I have tested these patches with mount/umount and device removal using > > > > > qemu monitor. For example. > > > > > > > > Is device removal mandatory? Can't this be made a non-removable > > > > device? Is there a good reason why removing the virtio-fs device > > > > makes sense? > > > > > > Hot plugging and unplugging virtio PCI adapters is common. I'd very > > > much like removal to work from the beginning. > > > > Can you give an example use case? > > David Gilbert mentioned this could be useful if daemon stops responding > or dies. One could remove device. That will fail all future requests > and allow unmounting filesystem. > > Havind said that, current implementation will help in above situation > only if there are no pending requests. If there are pending requests > and daemon stops responding, then removal will hang too, as we wait > for draining the queues. > > So at some point of time, we also need some sort of timeout functionality > where we end requests with error after a timeout. > > I feel we should support removing device at some point of time. But its > not necessarily a must have feature for first round. If there's no compelling reason to do it in the first round, than I'd prefer to not do it. More complexity -> more bugs. Thanks, Miklos
