[Top] [All Lists]

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

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [PATCH] (and bad attr2 bug) - pack xfs_sb_t for 64-bit arches
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Wed, 22 Nov 2006 10:24:55 -0600
Cc: Timothy Shimmin <tes@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <45647042.2040604@xxxxxxxxxxx>
References: <455CB54F.8080901@xxxxxxxxxxx> <455CE1E3.7020703@xxxxxxxxxxx> <45612621.5010404@xxxxxxxxxxx> <45627A4D.3020502@xxxxxxxxxxx> <1164157336.19915.43.camel@xxxxxxxxxxxxxxxxxxxx> <5A1AC29043EE33BEB778198A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <45647042.2040604@xxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
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.

The number of inodes that get pushed to btree mode should be a small %
of the
total number of inodes, especially on a root file system. So while attr2
not as efficient as it could be for that segment of the inodes the rest
of inodes
do benefit from attr2

By fixing the initial size calculation at least things like SElinux
which is adding one attr won't cause the attr segment to flip to extents
The second attr will cause the flip but not the first one.

> -Eric
Russell Cattelan <cattelan@xxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part

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