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.
>>
>> -Eric
>>
>>
> 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...
whee....
-Eric
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
forkoff
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
fixed
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
added
the header size to the initial split of the inode, at least the first
attr add
should go inline now. Which should be a win the big attr user right now
SElinux.
Including the 2 test script that have been used.
--
Russell Cattelan <cattelan@xxxxxxxxxxx>