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
-
To unsubscribe from this list: send the line
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
-
To unsubscribe from this list: send the line
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
>> #
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
On Fri, 04 Feb 2005 17:19:09 +0100, Andreas Gruenbacher wrote:
>On Fri, 2005-02-04 at 15:15, Mikael Pettersson wrote:
>
>> Plain 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
On Fri, 04 Feb 2005 17:19:09 +0100, Andreas Gruenbacher wrote:
On Fri, 2005-02-04 at 15:15, Mikael Pettersson wrote:
Plain 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
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
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
#
On Fri, 2005-02-04 at 15:15, Mikael Pettersson wrote:
> Plain 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
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.
> >
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
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
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
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
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
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
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
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
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 -
On Fri, 2005-02-04 at 15:15, Mikael Pettersson wrote:
Plain 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
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
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:
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:
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
24 matches
Mail list logo
