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/[email protected]?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