On Mon, 25 Feb 2008, Eric Sandeen wrote:
> Barry Naujok wrote:
> > On Sat, 23 Feb 2008 04:41:55 +1100, Eric Sandeen <sandeen@xxxxxxxxxxx>
> > wrote:
>
> ...
>
> >> My only thought here is that if you repair it, then use an older kernel
> >> w/o the fix, suddenly your fs behavior changes, whereas before you often
> >> got lucky, and both userspace & kernelspace swapped the same way, and
> >> you found the bits you were looking for out of luck :) (same goes for
> >> the recent kernel fix too, I guess)
> >
> > I believe the kernel code never tried to access "bad_features2" part
> > of the superblock, it always did the correct thing (correct me if I'm
> > wrong of course :).
>
> I'm fairly sure that it did; both userspace & kernelspace were doing the
> same thing, and endian-flipping "too much" ... but I'd have to test
> again to be sure.
In my case (x86_64, both kernel and userspace 64-bit), kernel accessed the
right place (features2), but userspace (mkfs.xfs) accessed wrong place
(bad_features2).
After patching mkfs.xfs with your patch, kernel began to use lazy-count
without additional bad_features2 changes.
There seems to be problem with sb_fdblocks count but kernel really look for
features2 and behaves differently if lazy-count is sets on right place.
jan
--
|