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.
--On 21 November 2006 7:02:16 PM -0600 Russell Cattelan <cattelan@xxxxxxxxxxx>
On Mon, 2006-11-20 at 22:02 -0600, Eric Sandeen wrote:
Eric Sandeen wrote:
> Eric Sandeen wrote:
>> ugh. it's broken on x86 too, so it's not just the alignment/padding,
>> although that should be fixed for cross-arch mounts.
> here's a testcase to corrupt it FWIW.
Ok, with expert collaboration from Russell, Barry, Tim,
Nathan, David, et al, how about this:
For btree dirs, we need a different calculation for the space
used in di_u, to set the minimum threshold for the fork offset...
This fixes my testcase, but as Tim points out -now- we need to compact
the btree ptrs, if we return (and use) an offset < current forkoff...
It turns out this only fixes one of the problems it is still quite easy
to corrupt indoes with attr2.
The following patch is a short term fix that address the problem of
moving without re-factoring the root inode btree root block.
Once the inode has be flipped to BTREE for the data space the forkoff is
to the that size, currently due to the way attr1 worked (fixed size
forkoff) the code is not handling the size to the root btree node due to
size changes in the attr portion of the inode.
The optimal solution is to adjust the data portion of the inode root
btree block down if space exists.
One easy fix that was resulting all attr add being pushed out of line is
the header size to the initial split of the inode, at least the first
should go inline now. Which should be a win the big attr user right now
Including the 2 test script that have been used.
Russell Cattelan <cattelan@xxxxxxxxxxx>