From: Allison Henderson <achender@linux.vnet.ibm.com>
To: Yongqiang Yang <xiaoqiangnk@gmail.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: question about punch hole
Date: Fri, 26 Aug 2011 15:35:31 -0700 [thread overview]
Message-ID: <4E581FB3.3020504@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAGBYx2abeJQBuZDV11WtrprmareZWSNkv-HGdLMvYoMB36mqZA@mail.gmail.com>
On 08/25/2011 07:53 PM, Yongqiang Yang wrote:
> Hi Allison,
>
> Currently, punch hole flushes all pages to disk and releases pages in
> page cache, and then calls ext4_ext_map_blocks.
>
> Assume that if a new page in the punching's range is mapped after
> releasing pages and before down_write i_data_sem,
> then ext4_ext_map_blocks will release map info of the page in extent
> tree. However, up layers does not know this, and they think the page
> is mapped.
>
> I can not find how punch hole handle the situation above. Could you
> shed a light on it?
>
>
Hi Yongqiang
This is a really good question and at the moment Im still looking into
it. :) The calling sequence in punch hole was modeled after truncate,
which also only locks i_data_sem when modifying the extent tree.
ext4_ext_map_blocks when called with the punch hole flag, only releases
blocks in the extent tree, using the same routines truncate does, but it
does not modify the state of the pages. Though that still does not
prevent the race condition you describe, so I am still investigating it.
I've found that I can catch a lot of race conditions by simply running
the stress test over night, and so far I havnt had anything like this
come up, but that certainly doesnt mean its not there. I will let you
know what I find. Thx!
Allison Henderson
next prev parent reply other threads:[~2011-08-26 22:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-26 2:53 question about punch hole Yongqiang Yang
2011-08-26 22:35 ` Allison Henderson [this message]
2011-08-27 9:04 ` Yongqiang Yang
2011-08-27 9:33 ` Yongqiang Yang
2011-08-28 1:09 ` Allison Henderson
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=4E581FB3.3020504@linux.vnet.ibm.com \
--to=achender@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=xiaoqiangnk@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).