All of lore.kernel.org
 help / color / mirror / Atom feed
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.