From: Eric Sandeen <sandeen@sgi.com>
To: linux-kernel@vger.kernel.org
Subject: [PATCH 2.6.13] clear_buffer_uptodate() in discard_buffer()
Date: Wed, 14 Sep 2005 16:25:40 -0500 [thread overview]
Message-ID: <43289554.7010606@sgi.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]
I was tracking down a problem in XFS, with this testcase:
(where blocksize = 1/4 page size)
seek out 4 blocks
write 2 blocks (EOF now at 6 blocks)
truncate back to 4 blocks + a few bytes
truncate out to 6 blocks
This should wind up with:
4 blocks of hole | 1 block of data | 1 block of hole
but instead gave:
4 blocks of hole | 2 blocks of data
The last extending truncate, which should lead to a hole of 1 filesystem block
at the end of the file, wound up getting allocated as an extent. I tracked
this down to the first truncate back, where we called discard_buffer() on the
buffer head covering the last block in the file. discard_buffer() clears
several bh state flags, and nulls b_bdev, but it does NOT clear the uptodate flag.
XFS later comes along and allocates blocks for the file (due to a periodic
sync, in the simplest case), and finds that the buffer_head over the last block
before EOF is Uptodate, and allocates a block where there should be a hole.
I submit this patch with some hesitation, because a few years ago, akpm
committed this changeset:
http://linux.bkbits.net:8080/linux-2.6/cset@1.373.70.7?nav=index.html|src/|src/fs|related/fs/buffer.c
which specifically -removed- the clearing of BH_Uptodate in discard_buffer().
Andrew had some concerns about clearing the bh uptodate flag without possibly
changing the page state, but didn't otherwise remember the details. :)
However, when we truncate down & call discard_buffer, this buffer head is now
out past EOF, and any other buffers also past EOF on this page have no state at
all; they also are in their initialized state from alloc_page_buffers with 0
b_state, and NULL b_bdev, etc. So by clearing Uptodate on this truncated
buffer, it simply joins it's friends at the end of the page.
Thanks,
-Eric
[-- Attachment #2: bh_uptodate.patch --]
[-- Type: text/x-patch, Size: 347 bytes --]
Signed-off-by: Eric Sandeen <sandeen.sgi.com>
--- a/fs/buffer.c 2005-09-14 15:54:19.000000000 -0500
+++ b/fs/buffer.c 2005-09-14 15:53:52.000000000 -0500
@@ -1549,6 +1549,7 @@
lock_buffer(bh);
clear_buffer_dirty(bh);
bh->b_bdev = NULL;
+ clear_buffer_uptodate(bh);
clear_buffer_mapped(bh);
clear_buffer_req(bh);
clear_buffer_new(bh);
reply other threads:[~2005-09-14 21:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=43289554.7010606@sgi.com \
--to=sandeen@sgi.com \
--cc=linux-kernel@vger.kernel.org \
/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.