All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Peng Tao <bergwolf@gmail.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	Dmitry Monakhov <dmonakhov@openvz.org>,
	Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Zheng Liu <wenqing.lz@taobao.com>
Subject: Re: [PATCH v2] vfs: fix a bug when we do some dio reads with append dio writes
Date: Sat, 30 Nov 2013 00:12:06 +0800	[thread overview]
Message-ID: <20131129161206.GA23032@gmail.com> (raw)
In-Reply-To: <CA+a=Yy5j+=JZ3yWHmfJwq5Thc+xkOEcAvrgQPTs8cayXV2a4Fg@mail.gmail.com>

On Fri, Nov 29, 2013 at 05:18:04PM +0800, Peng Tao wrote:
> On Fri, Nov 29, 2013 at 9:07 AM, Zheng Liu <gnehzuil.liu@gmail.com> wrote:
> >   generic_file_aio_read()
> >   ->do_generic_file_read()
> >     [fallback to buffered read]
> This seems to be another thing that you might want to fix. In
> generic_file_aio_read() of DIO, if pos >= isize, it also falls back to
> do_generic_file_read() but can just return instead.

Sorry, maybe I don't clarify the problem.  Actually this patch tries to
fix this problem that you pointed out.  When we do some append dio
writes, and we try to do some dio reads to get the last some data from
the same file, we will encounter this problem.  The root cause is that
we will fall back to buffered read if pos >= isize.  In first version
[1], I just let it return directly to fix the problem if pos >= isize.
But it's not perfect.

1. http://www.spinics.net/lists/linux-fsdevel/msg70358.html

> Or is there any
> historical reason to fall back there?

I also want to know why we do this. :)

Regards,
                                                - Zheng

      reply	other threads:[~2013-11-29 16:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-29  1:07 [PATCH v2] vfs: fix a bug when we do some dio reads with append dio writes Zheng Liu
2013-11-29  8:29 ` Jan Kara
2013-11-29  9:18 ` Peng Tao
2013-11-29 16:12   ` Zheng Liu [this message]

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=20131129161206.GA23032@gmail.com \
    --to=gnehzuil.liu@gmail.com \
    --cc=bergwolf@gmail.com \
    --cc=david@fromorbit.com \
    --cc=dmonakhov@openvz.org \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wenqing.lz@taobao.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.