Re: [PATCH] fs: nobh_truncate_page() fix

[Andrew Morton]

On Mon, 05 Mar 2007 17:10:11 -0600
Dave Kleikamp <shaggy@xxxxxxxxxxxxxxxxxx> wrote:

> On Mon, 2007-03-05 at 14:57 -0800, Andrew Morton wrote:
> > Is OK, I think.  nobh_prepare_write() brings the outside-from-and-to
> > sections of the page uptodate and memset in nobh_truncate_page() brings the
> > rest of the page uptodate.
> > 
> > We bring the to->PAGE_CACHE_SIZE section uptodate twice, which could be
> > optimised.
> 
> Why not have nobh_truncate_page() call prepare_write() with to =
> PAGE_CACHE_SIZE?  I don't really grok:
> 
> to = (offset + blocksize) & ~(blocksize - 1);

OK, let's say we have a 4k pagesize and a 1k fs blocksize and someone does
ftruncate(fd, 1024 + 100).

We need to:

- load bytes (0 ...  1024+100) from disk (these are live file data)

- zero the bytes (1024+100 ...  1024+1024) (these are data outside the
  truncation point, but inside the fs block which straddles the truncation
  point)

- zero the bytes (1024+1024 ...  4096) (these are the rest of the
  pagecache page, outside the truncation point).

- mark the page dirty so those zeroes outside the truncation point but
  inside the block which straddles i_size (ie: (1024+100 ...  1024+1024)
  get written back.

Now, it just so happens that

	nobh_prepare_write(NULL, page, 1024+100, 1024+1024)

will indeed load bytes (0 ...  1024+1024) from disk, and will then zero out
bytes (1024+100 ...  4096) for us (I think - assumes that ->get_block does
the right thing with buffer_mapped)).  We could exploit that knowledge of
prepare_write() internals in nobh_truncate_page().

But as it stands, nobh_truncate_page() is being formal and is not making
assumptions about what nobh_prepare_write() does with blocks outside
i_size.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/