From: Greg Kurz <groug@kaod.org>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>,
Cornelia Huck <cohuck@redhat.com>,
virtio-fs-list <virtio-fs@redhat.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Paolo Bonzini <pbonzini@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [Virtio-fs] [for-6.1 v3 3/3] virtiofsd: Add support for FUSE_SYNCFS request
Date: Tue, 11 May 2021 17:08:26 +0200 [thread overview]
Message-ID: <20210511170826.73b0b663@bahia.lan> (raw)
In-Reply-To: <CAOssrKfbzCnpHma-=tTRvwUecy_9RtJADzMb_uQ1yzzJStz1PA@mail.gmail.com>
On Tue, 11 May 2021 14:31:14 +0200
Miklos Szeredi <mszeredi@redhat.com> wrote:
> On Mon, May 10, 2021 at 5:55 PM Greg Kurz <groug@kaod.org> wrote:
> >
> > Honor the expected behavior of syncfs() to synchronously flush all data
> > and metadata on linux systems. Simply loop on all known submounts and
> > call syncfs() on them.
>
> Why not pass the submount's root to the server, so it can do just one
> targeted syncfs?
>
> E.g. somehting like this in fuse_sync_fs():
>
> args.nodeid = get_node_id(sb->s_root->d_inode);
>
> Thanks,
> Miklos
>
As Vivek already pointed out, there was some misunderstanding on
how submounts were supposed to work. Things got clearer since then :)
So, basically, we have two cases:
1) virtiofsd announces submounts : the d_automount implementation
creates a new super block and mounts the submount
2) virtiofsd doesn't announce submounts: the client only knows
about the top-level super block
You suggestion is for case 1) while this series was made with
case 2) in mind, hence the tracking of the super blocks in
the server.
Vivek and I discussed and agreed to address 2) later and
to just focus on 1) for now.
Your suggestion doesn't work with the current code base
because ->sync_fs() is never called on our submounts'
super blocks. This is because they don't have SB_BORN
set, which looks incorrect. A call to vfs_get_tree() would
fix it, but some code refactoring is needed in
fuse_dentry_automount() and virtio_fs_get_tree() for that.
Cheers,
--
Greg
next prev parent reply other threads:[~2021-05-11 15:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-10 15:55 [for-6.1 v3 0/3] virtiofsd: Add support for FUSE_SYNCFS request Greg Kurz
2021-05-10 15:55 ` [for-6.1 v3 2/3] virtiofsd: Track mounts Greg Kurz
2021-05-10 19:18 ` Vivek Goyal
2021-05-11 10:06 ` Greg Kurz
2021-05-10 15:55 ` [for-6.1 v3 3/3] virtiofsd: Add support for FUSE_SYNCFS request Greg Kurz
2021-05-10 19:15 ` Vivek Goyal
2021-05-11 10:09 ` Greg Kurz
2021-05-11 12:31 ` [Virtio-fs] " Miklos Szeredi
2021-05-11 12:54 ` Vivek Goyal
2021-05-11 14:49 ` Vivek Goyal
2021-05-11 15:08 ` Miklos Szeredi
2021-05-11 15:16 ` Vivek Goyal
2021-05-11 15:08 ` Greg Kurz [this message]
2021-05-10 15:58 ` [for-6.1 v3 0/3] " Greg Kurz
2021-11-10 19:48 ` Vivek Goyal
2021-11-15 14:30 ` Greg Kurz
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=20210511170826.73b0b663@bahia.lan \
--to=groug@kaod.org \
--cc=cohuck@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mst@redhat.com \
--cc=mszeredi@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=vgoyal@redhat.com \
--cc=virtio-fs@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).