[GIT PULL] XFS update

[GIT PULL] XFS update

[Tim Shimmin]

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 <dgc@sgi.com>
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

     Signed-off-by: David Chinner <dgc@sgi.com>
     Signed-off-by: Christoph Hellwig <hch@infradead.org>
     Signed-off-by: Tim Shimmin <tes@sgi.com>

commit 91ebecc74eeeeea0a2aa50bf1964ec2214a229c9
Author: David Chinner <dgc@sgi.com>
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

     Signed-off-by: David Chinner <dgc@sgi.com>
     Signed-off-by: Vlad Apostolov <vapo@sgi.com>
     Signed-off-by: Tim Shimmin <tes@sgi.com>

commit 4f57dbc6b5bae5a3978d429f45ac597ca7a3b8c6
Author: David Chinner <dgc@sgi.com>
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

     Signed-off-by: David Chinner <dgc@sgi.com>
     Signed-off-by: Christoph Hellwig <hch@infradead.org>
     Signed-off-by: Tim Shimmin <tes@sgi.com>

commit 5417169026c3df151adf5a65eb061278b0a72e69
Author: David Chinner <dgc@sgi.com>
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

     Signed-off-by: David Chinner <dgc@sgi.com>
     Signed-off-by: Christoph Hellwig <hch@infradead.org>
     Signed-off-by: Tim Shimmin <tes@sgi.com>

Thanks,
Tim.

Re: [GIT PULL] XFS update

[Linus Torvalds]

On Fri, 20 Jul 2007, Tim Shimmin wrote:
> 
> Please pull from the for-linus branch:
>     git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus

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

Re: [GIT PULL] XFS update

[Timothy Shimmin]

Linus Torvalds wrote:
> 
> On Fri, 20 Jul 2007, Tim Shimmin wrote:
>> Please pull from the for-linus branch:
>>     git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus
> 
> 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

Re: [GIT PULL] XFS update

[Linus Torvalds]

On Fri, 20 Jul 2007, Timothy Shimmin wrote:
> 
> The window between pulling in and applying changes was obviously
> large enough for Nick's changes to get in.

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