[Top] [All Lists]

Re: [PATCH] (and bad attr2 bug) - pack xfs_sb_t for 64-bit arches

To: Russell Cattelan <cattelan@xxxxxxxxxxx>
Subject: Re: [PATCH] (and bad attr2 bug) - pack xfs_sb_t for 64-bit arches
From: David Chinner <dgc@xxxxxxx>
Date: Fri, 24 Nov 2006 09:49:52 +1100
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, Timothy Shimmin <tes@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <1164212695.19915.65.camel@xxxxxxxxxxxxxxxxxxxx>
References: <455CB54F.8080901@xxxxxxxxxxx> <455CE1E3.7020703@xxxxxxxxxxx> <45612621.5010404@xxxxxxxxxxx> <45627A4D.3020502@xxxxxxxxxxx> <1164157336.19915.43.camel@xxxxxxxxxxxxxxxxxxxx> <5A1AC29043EE33BEB778198A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <45647042.2040604@xxxxxxxxxxx> <1164212695.19915.65.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/
On Wed, Nov 22, 2006 at 10:24:55AM -0600, Russell Cattelan wrote:
> On Wed, 2006-11-22 at 09:44 -0600, Eric Sandeen wrote:
> > Timothy Shimmin wrote:
> > > Thanks, Russell.
> > > 
> > > I've been going thru the irc and just started looking at the patch.
> > > I'll get back to you about it tomorrow.
> > > 
> > > I agree it would be good to have the fixed forkoff for data btree roots
> > > as the first fix. And look into redoing the btree root for a later change.
> > 
> > My only question is, how much does this defeat the purpose of attr2?
> Well from the standpoint that attr2 currently corrupts inodes anything
> to prevent that is good, since  currently attr2 can't be used at all.
> When the di_u is extent based the attr2 code works as expected, giving
> space to which ever segment gets there first.The attr2 code should still
> be a big win for most file/dir inodes since they are probably able to do
> their block mapping with local or extent mode.

I suggest that dbench -x might be the best way to determine the
perfomrance impact - attr1 on a single disk would get ~5MB/s; attr2
on the same disk for the same test gave about 50MB/s (IIRC). I'd
hope that this fix retains that kind of advantage for attr2....


Dave Chinner
Principal Engineer
SGI Australian Software Group

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