xfs-masters
[Top] [All Lists]

[xfs-masters] Re: [patch 1/3] xfs clean up shrinker games

To: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, David Chinner <dgc@xxxxxxx>
Subject: [xfs-masters] Re: [patch 1/3] xfs clean up shrinker games
From: Timothy Shimmin <tes@xxxxxxx>
Date: Mon, 14 May 2007 19:55:49 +1000
Cc: xfs-masters@xxxxxxxxxxx, rusty@xxxxxxxxxxxxxxx
In-reply-to: <20070512012452.055bf4a8.akpm@xxxxxxxxxxxxxxxxxxxx>
References: <200705110610.l4B6Agjq008466@xxxxxxxxxxxxxxxxxxx> <20070510232454.bc7d598d.akpm@xxxxxxxxxxxxxxxxxxxx> <20070512075350.GD85884050@xxxxxxx> <20070512012452.055bf4a8.akpm@xxxxxxxxxxxxxxxxxxxx>
Reply-to: xfs-masters@xxxxxxxxxxx
Sender: xfs-masters-bounce@xxxxxxxxxxx
Hi,

Yes, I got the msg after the last Linus push a few days ago :)
But I was away on Friday and before that there were no outstanding mods in
the TOT xfs tree to push.
I'll be pushing Dave's mods shortly to git.

I wouldn't say we've "neglected" the tree - I was never told that I
needed to keep it up-to-date with TOT until recently.
Hence just the periodic Linus pushes.
If the trees were the same then this could be totally automated but
alas they are not.
Anyway, let's see how we go going forward...:)

As for "ball juggling" the current scripts for doing this
(which select appropriate mods etc.) are more
robust/automated than the way things were done previously -
just need to use them more often ;-).

Okay, I've just converted the mods, built and done a quick test.
(I think Dave said he still has the zero_user_page one to go and I noticed
 the deprecated warning msg on build)

Please pull from:
    git://oss.sgi.com:8090/xfs/xfs-2.6

This will update the following files:

 fs/xfs/linux-2.6/xfs_buf.c   |   62 +++++++++++++++++++-----------------
 fs/xfs/linux-2.6/xfs_buf.h   |    2 +
 fs/xfs/linux-2.6/xfs_super.c |    8 -----
 fs/xfs/xfs_fsops.c           |    2 +
 fs/xfs/xfs_log.c             |   48 ++++++++++++++++++----------
 fs/xfs/xfs_mount.c           |   35 +++++++++++++-------
 fs/xfs/xfs_mount.h           |    1 +
 fs/xfs/xfs_rtalloc.c         |    4 ++
 fs/xfs/xfs_vfsops.c          |   73 ++++++++++++++++--------------------------
 9 files changed, 123 insertions(+), 112 deletions(-)

through these commits:

commit 23547ca541933404e08d6ba06091452ff7420739
Author: David Chinner <dgc@xxxxxxx>
Date:   Mon May 14 18:24:23 2007 +1000

    [XFS] Barriers need to be dynamically checked and switched off

    If the underlying block device sudden stops supporting barriers, we need
    to handle the -EOPNOTSUPP error in a sane manner rather than shutting
    downteh filesystem. If we get this error, clear the barrier flag, reissue
    the I/O, and tell the world bad things are occurring.

    SGI-PV: 964544
    SGI-Modid: xfs-linux-melb:xfs-kern:28568a

    Signed-off-by: David Chinner <dgc@xxxxxxx>
    Signed-off-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: Tim Shimmin <tes@xxxxxxx>

commit 82ac53af75bfe6918c4826733728a62f72119e07
Author: David Chinner <dgc@xxxxxxx>
Date:   Mon May 14 18:24:16 2007 +1000

    [XFS] Fix use-after-free during log unmount.

    Don't reference the log buffer after running the callbacks as the callback
    can trigger the log buffers to be freed during unmount.

    SGI-PV: 964545
    SGI-Modid: xfs-linux-melb:xfs-kern:28567a

    Signed-off-by: David Chinner <dgc@xxxxxxx>
    Signed-off-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: Tim Shimmin <tes@xxxxxxx>

commit 9aac40e94eb4b738de85f57bb2410d2bed2f3612
Author: David Chinner <dgc@xxxxxxx>
Date:   Mon May 14 18:24:09 2007 +1000

    [XFS] Sleeping with the ilock waiting for I/O completion is Bad.

    Recent fixes to the filesystem freezing code introduced a vn_iowait call
    in the middle of the sync code. Unfortunately, at the point where this
    call was added we are holding the ilock. The ilock is needed by I/O
    completion for unwritten extent conversion and now updating the file size.
    Hence I/o cannot complete if we hol dthe ilock while waiting for I/O
    completion.

    Fix up the bug and clean the code up around it.

    SGI-PV: 963674
    SGI-Modid: xfs-linux-melb:xfs-kern:28566a

    Signed-off-by: David Chinner <dgc@xxxxxxx>
    Signed-off-by: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: Tim Shimmin <tes@xxxxxxx>

commit aafe3b78c46087b5634568288f98a30da38cc852
Author: Nathan Scott <nscott@xxxxxxxxxx>
Date:   Mon May 14 18:24:02 2007 +1000

    [XFS] Don't grow filesystems past the size they can index.

    When growing a filesystem we don't check to see if the new size overflows
    the page cache index range, so we can do silly things like grow a
    filesystem page 16TB on a 32bit. Check new filesystem sizes against the
    limits the kernel can support.

    SGI-PV: 957886
    SGI-Modid: xfs-linux-melb:xfs-kern:28563a

    Signed-Off-By: Nathan Scott <nscott@xxxxxxxxxx>
    Signed-off-by: David Chinner <dgc@xxxxxxx>
    Signed-off-by: Tim Shimmin <tes@xxxxxxx>

commit 5ebcebedcb4323e665c75ad03faa6e014bfa44c5
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date:   Mon May 14 18:23:50 2007 +1000

    [XFS] Only use refcounted pages for I/O

    Many block drivers (aoe, iscsi) really want refcountable pages in bios,
    which is what almost everyone send down. XFS unfortunately has a few
    places where it sends down buffers that may come from kmalloc, which
    breaks them.

    Fix the places that use kmalloc()d buffers.

    SGI-PV: 964546
    SGI-Modid: xfs-linux-melb:xfs-kern:28562a

    Signed-Off-By: Christoph Hellwig <hch@xxxxxxxxxxxxx>
    Signed-off-by: David Chinner <dgc@xxxxxxx>
    Signed-off-by: Tim Shimmin <tes@xxxxxxx>


Cheers,
Tim.

--On 12 May 2007 1:24:52 AM -0700 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 
wrote:

>> I'll push these (and the other fixes I just checked in) to the XFS
>> git tree next week so you can pull them from there. We've neglected
>> that tree since Nathan left - we're still picking up all the balls
>> he was juggling....
>
> OK, thanks.  Please do keep the git tree up to date - it does get you a
> decent bit of early external testing.  Plus it give me visibility of
> forthcoming clashes between your new stuff and other people's new stuff.
>
>> > (Of course I won't know when it's been applied because the XFS tree is
>> > sekkrit.  Hint.)
>>
>> We do post commit messages to the xfs list - is there somewhere else
>> you'd like them sent? Or would updating the git tree as we commit patches
>> to the master tree be sufficient?
>>
>
> Sync promptly with git://oss.sgi.com:8090/xfs/xfs-2.6, please.





<Prev in Thread] Current Thread [Next in Thread>