From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs
Date: Tue, 01 Mar 2011 20:32:09 +0530 [thread overview]
Message-ID: <87k4gievf2.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <AANLkTimBfppFvj_=01pCy3A94RWq4kEq3GBriSj2F9rL@mail.gmail.com>
On Tue, 1 Mar 2011 10:22:07 +0000, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Tue, Mar 1, 2011 at 6:38 AM, Aneesh Kumar K.V
> <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > ---
> > hw/9pfs/virtio-9p.c | 31 +++++++++++++++++++++++++++++++
> > hw/9pfs/virtio-9p.h | 2 ++
> > 2 files changed, 33 insertions(+), 0 deletions(-)
> >
> > diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
> > index c4b0198..882f4f3 100644
> > --- a/hw/9pfs/virtio-9p.c
> > +++ b/hw/9pfs/virtio-9p.c
> > @@ -1978,6 +1978,36 @@ static void v9fs_fsync(V9fsState *s, V9fsPDU *pdu)
> > v9fs_post_do_fsync(s, pdu, err);
> > }
> >
> > +static void v9fs_post_do_syncfs(V9fsState *s, V9fsPDU *pdu, int err)
> > +{
> > + if (err == -1) {
> > + err = -errno;
> > + }
> > + complete_pdu(s, pdu, err);
> > +}
> > +
> > +static void v9fs_syncfs(V9fsState *s, V9fsPDU *pdu)
> > +{
> > + int err;
> > + int32_t fid;
> > + size_t offset = 7;
> > + V9fsFidState *fidp;
> > +
> > + pdu_unmarshal(pdu, offset, "d", &fid);
> > + fidp = lookup_fid(s, fid);
> > + if (fidp == NULL) {
> > + err = -ENOENT;
> > + v9fs_post_do_syncfs(s, pdu, err);
> > + return;
> > + }
> > + /*
> > + * We don't have per file system syncfs
> > + * So just return success
> > + */
> > + err = 0;
> > + v9fs_post_do_syncfs(s, pdu, err);
> > +}
>
> Please explain the semantics of P9_TSYNCFS. Won't returning success
> without doing anything lead to data integrity issues?
I should actually do the 9P Operation format as commit message. Will
add in the next update. Whether returning here would cause a data
integrity issue, it depends what sort of guarantee we want to
provide. So calling sync on the guest will cause all the dirty pages in
the guest to be flushed to host. Now all those changes are in the host
page cache and it would be nice to flush them as a part of sync but
then since we don't have a per file system sync, the above would imply
we flush all dirty pages on the host which can result in large
performance impact.
>
> It seems unnecessary to split v9fs_post_do_syncfs() into its own
> function since there is no blocking point here and a callback will not
> be needed.
>
That is done as a place holder to add the per file system sync call
once we get the support
http://thread.gmane.org/gmane.linux.file-systems/44628
-aneesh
next prev parent reply other threads:[~2011-03-01 15:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-01 6:38 [Qemu-devel] [PATCH -V2 1/6] hw/9pfs: Add V9fsfidmap in preparation for adding fd reclaim Aneesh Kumar K.V
2011-03-01 6:38 ` [Qemu-devel] [PATCH -V2 2/6] hw/9pfs: Add file descriptor reclaim support Aneesh Kumar K.V
2011-03-01 6:38 ` [Qemu-devel] [PATCH -V2 3/6] hw/9pfs: Use v9fs_do_close instead of close Aneesh Kumar K.V
2011-03-01 6:38 ` [Qemu-devel] [PATCH -V2 4/6] hw/9pfs: Implement syncfs Aneesh Kumar K.V
2011-03-01 10:22 ` Stefan Hajnoczi
2011-03-01 15:02 ` Aneesh Kumar K. V [this message]
2011-03-01 15:59 ` Stefan Hajnoczi
2011-03-01 18:02 ` Aneesh Kumar K. V
2011-03-01 20:27 ` Stefan Hajnoczi
2011-03-02 5:05 ` Aneesh Kumar K. V
2011-03-02 10:20 ` Stefan Hajnoczi
2011-03-02 11:28 ` Aneesh Kumar K. V
2011-03-01 6:38 ` [Qemu-devel] [PATCH -V2 5/6] hw/9pfs: Add open flag to fid Aneesh Kumar K.V
2011-03-01 6:38 ` [Qemu-devel] [PATCH -V2 6/6] hw/9pfs: Add directory reclaim support Aneesh Kumar K.V
2011-03-01 9:28 ` [Qemu-devel] Re: [PATCH -V2 1/6] hw/9pfs: Add V9fsfidmap in preparation for adding fd reclaim Aneesh Kumar K. V
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=87k4gievf2.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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).