I believe there is some accounting error in the ext3 code
for the case when CONFIG_EXT3_FS_XATTR is not selected.
Whenever any one of my development boxes triggers an fsck
at boot because some file system, usually /, has been mounted
sufficiently many times, an inconsistency error occurs:
Extended attribute block N has reference count M, should be M'.
where M' is much less than M. As I drop into single-user and
run fsck, it finds at lot occurrences of this error, followed by:
Block bitmap differences ...
and then:
Free blocks count wrong
(always too low, i.e. I have more free blocks than the fs records).
This occurs on all my boxes, with different CPUs (x86/x86-64/ppc)
and different chipsets (Intel, Promise, VIA, Apple), and basically
the only commonalities are:
- they dual boot the most recent 2.4 and 2.6 kernels, and I switch often
- all file systems are ext3
- all XATTR stuff is disabled
/Mikael
Hi,
On Thu, 2005-02-03 at 22:42, Mikael Pettersson wrote:
> I believe there is some accounting error in the ext3 code
> for the case when CONFIG_EXT3_FS_XATTR is not selected.
>
> Whenever any one of my development boxes triggers an fsck
> at boot because some file system, usually /, has been mounted
> sufficiently many times, an inconsistency error occurs
In which kernel(s) exactly? There was a fix for that applied fairly
recently upstream.
> Extended attribute block N has reference count M, should be M'.
> This occurs on all my boxes, with different CPUs (x86/x86-64/ppc)
> and different chipsets (Intel, Promise, VIA, Apple), and basically
> the only commonalities are:
> - they dual boot the most recent 2.4 and 2.6 kernels, and I switch often
> - all file systems are ext3
> - all XATTR stuff is disabled
I'm not sure how you get this if all xattr stuff is disabled! Are you
sure you're not using SELinux or ACLs, for example?
--Stephen
Stephen C. Tweedie writes:
> Hi,
>
> On Thu, 2005-02-03 at 22:42, Mikael Pettersson wrote:
> > I believe there is some accounting error in the ext3 code
> > for the case when CONFIG_EXT3_FS_XATTR is not selected.
> >
> > Whenever any one of my development boxes triggers an fsck
> > at boot because some file system, usually /, has been mounted
> > sufficiently many times, an inconsistency error occurs
>
> In which kernel(s) exactly? There was a fix for that applied fairly
> recently upstream.
I've been seeing this over the last couple of months, with
(at least) 2.4.28 and newer, and 2.6.9 and newer standard kernels.
But since I dual boot and switch kernels often, I can't point
at any given kernel or kernel series as being the culprit.
How recent was that fix? Maybe I'm seeing the aftereffects of
pre-fix corruption?
> > Extended attribute block N has reference count M, should be M'.
>
> > This occurs on all my boxes, with different CPUs (x86/x86-64/ppc)
> > and different chipsets (Intel, Promise, VIA, Apple), and basically
> > the only commonalities are:
> > - they dual boot the most recent 2.4 and 2.6 kernels, and I switch often
> > - all file systems are ext3
> > - all XATTR stuff is disabled
>
> I'm not sure how you get this if all xattr stuff is disabled! Are you
> sure you're not using SELinux or ACLs, for example?
Absolutely. I use no xattrs, ACLs, or SELinux at all, and I always
disable those features in my kernels.
/Mikael
Hi,
On Fri, 2005-02-04 at 08:25, Mikael Pettersson wrote:
> > In which kernel(s) exactly? There was a fix for that applied fairly
> > recently upstream.
>
> I've been seeing this over the last couple of months, with
> (at least) 2.4.28 and newer, and 2.6.9 and newer standard kernels.
> But since I dual boot and switch kernels often, I can't point
> at any given kernel or kernel series as being the culprit.
Plain upstream 2.4.28? If so, that's probably the trouble, as 2.4
doesn't have any xattr support, so if you delete a file on 2.4 it won't
delete the xattr block for it.
> How recent was that fix? Maybe I'm seeing the aftereffects of
> pre-fix corruption?
It went in on the 15th of January this year.
--Stephen
Stephen C. Tweedie writes:
> Hi,
>
> On Fri, 2005-02-04 at 08:25, Mikael Pettersson wrote:
>
> > > In which kernel(s) exactly? There was a fix for that applied fairly
> > > recently upstream.
> >
> > I've been seeing this over the last couple of months, with
> > (at least) 2.4.28 and newer, and 2.6.9 and newer standard kernels.
> > But since I dual boot and switch kernels often, I can't point
> > at any given kernel or kernel series as being the culprit.
>
> Plain upstream 2.4.28? If so, that's probably the trouble, as 2.4
> doesn't have any xattr support, so if you delete a file on 2.4 it won't
> delete the xattr block for it.
2.4.28 - certainly I've used that at lot.
> > How recent was that fix? Maybe I'm seeing the aftereffects of
> > pre-fix corruption?
>
> It went in on the 15th of January this year.
Is it in 2.4.29?
/Mikael
Hi,
On Fri, 2005-02-04 at 13:10, Mikael Pettersson wrote:
> > Plain upstream 2.4.28? If so, that's probably the trouble, as 2.4
> > doesn't have any xattr support, so if you delete a file on 2.4 it won't
> > delete the xattr block for it.
>
> 2.4.28 - certainly I've used that at lot.
But plain upstream 2.4.28, or a vendor kernel? Like I just said,
upstream doesn't have xattr support.
> > > How recent was that fix? Maybe I'm seeing the aftereffects of
> > > pre-fix corruption?
> >
> > It went in on the 15th of January this year.
>
> Is it in 2.4.29?
No, it couldn't be. It was an xattr fix. 2.4.29 doesn't have xattrs,
so the fix isn't relevant there.
--Stephen
Stephen C. Tweedie writes:
> Hi,
>
> On Fri, 2005-02-04 at 13:10, Mikael Pettersson wrote:
>
> > > Plain upstream 2.4.28? If so, that's probably the trouble, as 2.4
> > > doesn't have any xattr support, so if you delete a file on 2.4 it won't
> > > delete the xattr block for it.
> >
> > 2.4.28 - certainly I've used that at lot.
>
> But plain upstream 2.4.28, or a vendor kernel? Like I just said,
> upstream doesn't have xattr support.
Plain http://www.kernel.org kernels always.
/Mikael
On Fri, 2005-02-04 at 15:15, Mikael Pettersson wrote:
> Plain http://www.kernel.org kernels always.
Good, it's no bug then. Stephen already explained what's going on: when
a file has xattrs and you delete the file while running a kernel without
xattr support, the xattr block's refcount is not decremented. You end up
with a reference count that is one too high. This won't result in
filesystem corruption, but e2fsck will fix up the refcounts for you.
Those are the mesages you were getting.
Regards,
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX GMBH
On Fri, 04 Feb 2005 17:19:09 +0100, Andreas Gruenbacher wrote:
>On Fri, 2005-02-04 at 15:15, Mikael Pettersson wrote:
>
>> Plain http://www.kernel.org kernels always.
>
>Good, it's no bug then. Stephen already explained what's going on: when
>a file has xattrs and you delete the file while running a kernel without
>xattr support, the xattr block's refcount is not decremented. You end up
>with a reference count that is one too high. This won't result in
>filesystem corruption, but e2fsck will fix up the refcounts for you.
>Those are the mesages you were getting.
It explains why ext3 file systems acquire inconsistencies when
people dual-boot 2.6 and 2.4. It does not explain why 2.6 allocated
the xattr blocks in the first place; as I wrote initially, I
have disabled the xattrs stuff:
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
/Mikael
On Sat, 2005-02-05 at 13:39, Mikael Pettersson wrote:
> [...] It does not explain why 2.6 allocated
> the xattr blocks in the first place; as I wrote initially, I
> have disabled the xattrs stuff:
>
> CONFIG_EXT3_FS=y
> # CONFIG_EXT3_FS_XATTR is not set
The filesystem in question must have been used with a kernel that was
xattr aware once. You could also have been using ext2. Maybe you ran
selinux at some point, or similar. Can you boot into a kernel with
CONFIG_EXT3_FS_XATTR enabled, and ``getfattr -m- -d -R .'' on the
filesystem in question? This gives you a full xattr dump.
Regards,
--
Andreas Gruenbacher <[email protected]>
SUSE Labs, SUSE LINUX GMBH
On Sat, 05 Feb 2005 15:20:00 +0100, Andreas Gruenbacher wrote:
>On Sat, 2005-02-05 at 13:39, Mikael Pettersson wrote:
>> [...] It does not explain why 2.6 allocated
>> the xattr blocks in the first place; as I wrote initially, I
>> have disabled the xattrs stuff:
>>
>> CONFIG_EXT3_FS=y
>> # CONFIG_EXT3_FS_XATTR is not set
>
>The filesystem in question must have been used with a kernel that was
>xattr aware once. You could also have been using ext2. Maybe you ran
>selinux at some point, or similar. Can you boot into a kernel with
>CONFIG_EXT3_FS_XATTR enabled, and ``getfattr -m- -d -R .'' on the
>filesystem in question? This gives you a full xattr dump.
Done. According to that command, there are no xattrs anywhere
on any of the affected file systems. So it seems my self-compiled
xattr-disabled 2.6 kernels aren't to blame.
That leaves either the FC2 or FC3 installer kernels: one of
them must have created the xattrs. I don't know why/when they
were leaked, but this is consistent with the fact that I've
only seen fsck complain about the xattr blocks once on any
given file system.
Sorry about the false alarm.
/Mikael
Hi,
On Sat, 2005-02-05 at 19:49, Mikael Pettersson wrote:
> That leaves either the FC2 or FC3 installer kernels: one of
> them must have created the xattrs.
An FC3 install with SELinux would certainly create xattrs. Everywhere.
--Stephen