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 1/2] hw/9pfs: Add new virtfs option cache=writethrough to skip host page cache
Date: Wed, 12 Oct 2011 18:49:23 +0530 [thread overview]
Message-ID: <87r52iuz38.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAJSP0QV-PKUoaxgvgJ5mwOfMjo5GAN7kBUhZYiSUk_Rs1SznNA@mail.gmail.com>
On Wed, 12 Oct 2011 10:55:21 +0100, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> On Mon, Oct 10, 2011 at 10:06 AM, Aneesh Kumar K.V
> <aneesh.kumar@linux.vnet.ibm.com> wrote:
> > diff --git a/hw/9pfs/virtio-9p-handle.c b/hw/9pfs/virtio-9p-handle.c
> > index 5c8b5ed..441a37f 100644
> > --- a/hw/9pfs/virtio-9p-handle.c
> > +++ b/hw/9pfs/virtio-9p-handle.c
> > @@ -202,6 +202,15 @@ static ssize_t handle_pwritev(FsContext *ctx, int fd, const struct iovec *iov,
> > return writev(fd, iov, iovcnt);
>
> The sync_file_range(2) call below is dead-code since we'll return
> immediately after writev(2) completes. The writev(2) return value
> needs to be saved temporarily and then returned after
> sync_file_range(2).
Missed that. Will fix in the next update
>
> > }
> > #endif
> > + if (ctx->cache_flags & V9FS_WRITETHROUGH_CACHE) {
>
> -drive cache=writethrough means something different from 9pfs
> "writethrough". This is confusing so I wonder if there is a better
> name like immediate write-out.
>
cache=immediate-write-out ?
> > + /*
> > + * Initiate a writeback. This is not a data integrity sync.
> > + * We want to ensure that we don't leave dirty pages in the cache
> > + * after write when cache=writethrough is sepcified.
> > + */
> > + sync_file_range(fd, offset, 0,
> > + SYNC_FILE_RANGE_WAIT_BEFORE | SYNC_FILE_RANGE_WRITE);
> > + }
>
> I'm not sure whether SYNC_FILE_RANGE_WAIT_BEFORE is necessary. As a
> best-effort mechanism just SYNC_FILE_RANGE_WRITE does the job although
> a client that rapidly rewrites may be able to leave dirty pages in the
> host page cache
Shouldn't we prevent this ? That is the reason for me to use that
WAIT_BEFORE ?
>. SYNC_FILE_RANGE_WAIT_BEFORE ensures that dirty pages
> get written out but it is no longer asynchronous because it blocks.
-aneesh
next prev parent reply other threads:[~2011-10-12 13:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-07 6:46 [Qemu-devel] [PATCH 1/2] hw/9pfs: Add new virtfs option cache=writethrough to skip host page cache Aneesh Kumar K.V
2011-10-07 6:46 ` [Qemu-devel] [PATCH 2/2] qemu-options.hx: Update virtfs command documentation Aneesh Kumar K.V
2011-10-08 11:24 ` [Qemu-devel] [PATCH 1/2] hw/9pfs: Add new virtfs option cache=writethrough to skip host page cache Stefan Hajnoczi
2011-10-09 15:34 ` Aneesh Kumar K.V
2011-10-09 16:16 ` Stefan Hajnoczi
2011-10-09 18:35 ` Aneesh Kumar K.V
2011-10-10 4:54 ` Stefan Hajnoczi
2011-10-10 9:06 ` Aneesh Kumar K.V
2011-10-12 9:55 ` Stefan Hajnoczi
2011-10-12 13:19 ` Aneesh Kumar K.V [this message]
2011-10-12 14:32 ` Stefan Hajnoczi
2011-10-12 15:15 ` Aneesh Kumar K.V
2011-10-13 14:45 ` Stefan Hajnoczi
-- strict thread matches above, loose matches on Subject: below --
2011-06-06 17:17 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=87r52iuz38.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).