[Top] [All Lists]

Re: [PATCH -mm] rescue large xfs preferred iosize from the inode diet pa

To: Andrew Morton <akpm@xxxxxxxx>
Subject: Re: [PATCH -mm] rescue large xfs preferred iosize from the inode diet patch
From: Timothy Shimmin <tes@xxxxxxx>
Date: Mon, 25 Sep 2006 18:02:33 +1000
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, xfs mailing list <xfs@xxxxxxxxxxx>
In-reply-to: <20060922161040.609286fa.akpm@xxxxxxxx>
References: <45131334.6050803@xxxxxxxxxxx> <45134472.7080002@xxxxxxx> <20060922161040.609286fa.akpm@xxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Macintosh/20060909)
Andrew Morton wrote:
On Fri, 22 Sep 2006 12:03:30 +1000

Looked at your patch and then at our xfs code in the tree and
the existing code is different than what yours is based on.
I then noticed in the logs Nathan has actually made changes for this:

revision 1.254
date: 2006/07/17 10:46:05;  author: nathans;  state: Exp;  lines: +20 -5
modid: xfs-linux-melb:xfs-kern:26565a
Update XFS for i_blksize removal from generic inode structure
I even reviewed the change (and I don't remember it - getting old).

I looked at the mods scheduled for 2.6.19 and this is one of them.

So the fix for this is coming soon (and the fix is different from the
one above).

eh?  Eric's patch is based on -mm, which includes the XFS git tree.  If I
go and merge the inode-diet patches from -mm, XFS gets broken until you
guys merge the above mystery patch.  (I prefer to merge the -mm patches
after all the git trees have gone, but sometimes maintainers dawdle and I
get bored of waiting).

Is git://oss.sgi.com:8090/nathans/xfs-2.6 obsolete, or are you hiding stuff
from me?  ;)

We're still getting our act together since Nathan is no longer here.
Going forward the new git tree is at:

This has some more recent changes than the "nathans" one but
is far from up to date with the internal sgi tree and the external
cvs tree (as you noticed with the nathans one:).

I will get the "xfs" one updated in the next day or so.

(Aside: for some strange reason, the "nathans" one has 3 extra
 mods (commits) and as expected (to me:) the "xfs" one has 10 extra
 mods (commits) and there is about 46 mods (including missing 3)
 pending for the "xfs" tree.
 If we end up moving from our internal SCM to git at some point,
 this could make the updates less of a hassle:).


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