XFS update

Hi Linus,

Please pull from the for-linus branch:

    git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus

This will update the following files:

 fs/buffer.c                 |   47 +++++++++++++++++++++++++++++++++++++++++++
 fs/xfs/linux-2.6/xfs_file.c |   16 ++++++++++++++
 fs/xfs/xfs_vnodeops.c       |   30 +++++++++++++++++++++++++-
 include/linux/buffer_head.h |    2 +
 4 files changed, 93 insertions(+), 2 deletions(-)

through these commits:

commit c32676eea19ce29cb74dba0f97b085e83f6b8915

Author: David Chinner <[email protected]>
Date:   Thu Jul 19 16:28:58 2007 +1000

[XFS] Fix inode size update before data write in xfs_setattr

When changing the file size by a truncate() call, we log the change in the inode size. However, we do not flush any outstanding data that might not have been written to disk, thereby violating the data/inode size update order. This can leave files full of NULLs on crash.

Hence if we are truncating the file, flush any unwritten data that may lie between the curret on disk inode size and the new inode size that is being logged to ensure that ordering is preserved.

SGI-PV: 966308
SGI-Modid: xfs-linux-melb:xfs-kern:29174a

commit 91ebecc74eeeeea0a2aa50bf1964ec2214a229c9

Author: David Chinner <[email protected]>
Date:   Thu Jul 19 16:28:30 2007 +1000

[XFS] Allow punching holes to free space when at ENOSPC

Make the free file space transaction able to dip into the reserved blocks to ensure that we can successfully free blocks when the filesystem is at ENOSPC.

SGI-PV: 967788
SGI-Modid: xfs-linux-melb:xfs-kern:29167a

commit 4f57dbc6b5bae5a3978d429f45ac597ca7a3b8c6

Author: David Chinner <[email protected]>
Date:   Thu Jul 19 16:28:17 2007 +1000

[XFS] Implement ->page_mkwrite in XFS.

Hook XFS up to ->page_mkwrite to ensure that we know about mmap pages being written to. This allows use to do correct delayed allocation and ENOSPC checking as well as remap unwritten extents so that they get converted correctly during writeback. This is done via the generic block_page_mkwrite code.

SGI-PV: 940392
SGI-Modid: xfs-linux-melb:xfs-kern:29149a

commit 5417169026c3df151adf5a65eb061278b0a72e69

Author: David Chinner <[email protected]>
Date:   Thu Jul 19 17:39:55 2007 +1000

[FS] Implement block_page_mkwrite.

Many filesystems need a ->page-mkwrite callout to correctly set up pages that have been written to by mmap. This is especially important when mmap is writing into holes as it allows filesystems to correctly account for and allocate space before the mmap write is allowed to proceed.

Protection against truncate races is provided by locking the page and checking to see whether the page mapping is correct and whether it is beyond EOF so we don't end up allowing allocations beyond the current EOF or changing EOF as a result of a mmap write.

SGI-PV: 940392
SGI-Modid: 2.6.x-xfs-melb:linux:29146a

Thanks,
Tim.

Ok, this got some conflicts with Nick's VM fault patches, but I fixed them up since they looked trivial, and pushed out the result. Please do verify that it all works and makes sense, though...

Linus

Okay, sorry and thanks.

The window between pulling in and applying changes was obviously large enough for Nick's changes to get in.
I did pull in, and then had hassles in converting changes between sgi dev tree and git mainline. Then by the time they were fixed, scripts updated, had dinner, tree built, had failure with posix_test_lock (fixed that - then noticed others fixed it - wish I had pulled in at this stage:) and ran thru some qa, Nick's changes must have gone in.
Ok, next time must remember to repull in latest just before sending out as a final check.

--Tim

Don't worry.

Basically, merging is my job, and I happily do it. If I hit something that makes me nervous enough, I'll just push back and say "please merge this for me", but if I merge up conflicts on my own, I generally just let people know that I did it - not because it's a *problem*, but as a heads-up to let people know that they should double-check the end result.

Quite frankly, real merge conflicts happen rarely enough that it really isn't a problem. And 99% of the time, the conflicts are really pretty damn obvious, and doing them isn't a problem at all. So even when I ask people to "please check", most of the time I expect that the end result is fine.

So my "please double-check" was in no way meant to be a criticism or a "please do this better next time". It was _literally_ just meant to be just that and nothing more: a "please double-check", especially since for something like XFS, I'm not actually doing any testing personally.

So no worries.

Linus