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....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|