1:58 p.m.
I have been happily running Fedora Core 2 for a year.
I just tried to install Fedora Core 4T3, but it fails with:
-------------------------------------
There was an error installing cracklib-dicts-2.8.2-1. This can
indicate media failure, lack of disk space, and/or hardware problems.
This is a fatal error and your install will be aborted.
-------------------------------------
If I switch over to F3, I see:
-------------------------------------
Setting file_context_path to /etc/selinux/targeted/contexts/file_contexts
-------------------------------------
F4 shows:
-------------------------------------
<6>SELinux: initialized (dev hda3, type xfs), uses xattr
<4>post_create: setxatter failed, rc=1 (dev=hda7 ino=16449)
-------------------------------------
My partion layout is:
hda1: /boot (ext3)
hda2: swap
hda3: /home (xfs)
hda4: extended
hda5: / (Fedora core 2) (ext3)
hda6: / (alternate root) (jfs)
hda7: / (Fedora core 4T3) (jfs)
I booted off the DVD with "linux jfs", so it would allow me to format
the root partion with jfs.
I told it not to install SELinux.
I did test the media, and it is fine. Pretty sure my hardware is
okay, since Fedora Core 2 is quite happy running on it.
Any other information I can provide to help track this problem down?
Thanks,
John
1:25 a.m.
On Sunday 22 May 2005 04:58, John P Poet <jppoet(a)gmail.com> wrote:
I just tried to install Fedora Core 4T3, but it fails with:
-------------------------------------
There was an error installing cracklib-dicts-2.8.2-1. This can
indicate media failure, lack of disk space, and/or hardware problems.
This is a fatal error and your install will be aborted.
-------------------------------------
I booted off the DVD with "linux jfs", so it would allow me to format
the root partion with jfs.
There will be errors setting XATTRs when disk space runs out. Setting an
XATTR to a value that hasn't previously been used or setting an instance of
an xattr name/value combination that is congruent to 0 mod 1024 will result
in allocating a new disk block and will fail if there is no free block.
Anaconda is supposed to calculate the space needed for installation and refuse
to install a combination of packages that will exceed the space. Maybe
anaconda has the wrong idea about the amount of disk space required for JFS
meta-data and will allow you to install what it thinks is 99% space usage
which is really >100%.
I told it not to install SELinux.
This is a bug then. If you tell it not to install SE Linux then it shouldn't
set any xattrs. Did you tell it via "selinux=0" or via the GUI in anaconda?
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
5:13 p.m.
On 5/22/05, Russell Coker <russell(a)coker.com.au> wrote:
On Sunday 22 May 2005 04:58, John P Poet <jppoet(a)gmail.com>
wrote:
> I just tried to install Fedora Core 4T3, but it fails with:
> -------------------------------------
> There was an error installing cracklib-dicts-2.8.2-1. This can
> indicate media failure, lack of disk space, and/or hardware problems.
> This is a fatal error and your install will be aborted.
> -------------------------------------
>
> I booted off the DVD with "linux jfs", so it would allow me to format
> the root partion with jfs.
There will be errors setting XATTRs when disk space runs out. Setting an
XATTR to a value that hasn't previously been used or setting an instance of
an xattr name/value combination that is congruent to 0 mod 1024 will result
in allocating a new disk block and will fail if there is no free block.
Anaconda is supposed to calculate the space needed for installation and refuse
to install a combination of packages that will exceed the space. Maybe
anaconda has the wrong idea about the amount of disk space required for JFS
meta-data and will allow you to install what it thinks is 99% space usage
which is really >100%.
I told it to format the "root" partition with JFS. The partition in
question is 10gig, so it should have had plenty of space. That also
seemed to be the first package it tried to install.
> I told it not to install SELinux.
This is a bug then. If you tell it not to install SE Linux then it shouldn't
set any xattrs. Did you tell it via "selinux=0" or via the GUI in anaconda?
Using the GUI in anaconda.
I reproduced the problem three times before posting. I finally told
it to format the root partition with XFS instead of JFS, and then it
worked fine.
It looks to me like there is a problem using JFS with Fedora Core 4T3.
John
5:15 p.m.
On 5/22/05, Arjan van de Ven <arjanv(a)redhat.com> wrote:
> I booted off the DVD with "linux jfs", so it would allow me to format
> the root partion with jfs.
please consider not using jfs instead.
Indeed, XFS works fine. Is it documented somewhere that JFS does not
work with Fedora Core? Maybe installing/booting with "linux jfs"
should be disabled?
Thanks,
John
1:15 a.m.
On Sun, May 22, 2005 at 04:15:16PM -0600, John P Poet wrote:
On 5/22/05, Arjan van de Ven <arjanv(a)redhat.com> wrote:
>
> > I booted off the DVD with "linux jfs", so it would allow me to
format
> > the root partion with jfs.
>
> please consider not using jfs instead.
Indeed, XFS works fine. Is it documented somewhere that JFS does not
work with Fedora Core? Maybe installing/booting with "linux jfs"
should be disabled?
"linux jfs" isn't documented afaik.
The simple situation is that ext3 is basically all we really support and
test, the rest may or may not work. Is there a reason you want to use JFS ?
(ext3 in fc3/fc4 is pretty competative with any of the other filesystems on
just about every workload performance wise... the benchmarks I've seen from
others hardly ever put JFS on top for anything nowadays so JFS strikes me as
a bit of an odd choice)
1:50 a.m.
On Mon, 23 May 2005, Arjan van de Ven wrote:
"linux jfs" isn't documented afaik.
The simple situation is that ext3 is basically all we really support and
test, the rest may or may not work. Is there a reason you want to use JFS ?
(ext3 in fc3/fc4 is pretty competative with any of the other filesystems on
just about every workload performance wise... the benchmarks I've seen from
others hardly ever put JFS on top for anything nowadays so JFS strikes me as
a bit of an odd choice)
xfs and reiserfs are _huge_ wins over ext3 for news servers.
Any even for large ISP mailservers xfs and reiserfs are still huge wins
over ext3.
Also our 'totally corrupt filesystems' statistics are much higher on ext3
than reiserfs so given all the above we've stopped deploying ext3 in new
servers and only deploy reiserfs in new servers now.
A pity selinux doesnt work on reiserfs yet, but selinux has serious
growing pains atm so we will wait for selinux to stabilize before we worry
about that.
ext3 might be just dandy for desktops which I expect is the primary target
market for fc3/fc4 but reiserfs/xfs are much better for typical ISP
workloads.
-Dan
2:04 a.m.
On Sun, 2005-05-22 at 23:50 -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
> "linux jfs" isn't documented afaik.
>
> The simple situation is that ext3 is basically all we really support and
> test, the rest may or may not work. Is there a reason you want to use JFS ?
> (ext3 in fc3/fc4 is pretty competative with any of the other filesystems on
> just about every workload performance wise... the benchmarks I've seen from
> others hardly ever put JFS on top for anything nowadays so JFS strikes me as
> a bit of an odd choice)
xfs and reiserfs are _huge_ wins over ext3 for news servers.
1) Did you try this on 2.4 or 2.6? 2.6 ext3 (with htree and
reservations) is like a 3x improvement over the 2.4 ext3 in many
workloads and is sometimes even slightly better than reiserfs in the
"milions of files in a directory" scenario.
2) Did you set the ext3 journalling mode to be on par with reiserfs/xfs?
(By default ext3 uses a more strict journalling mode to increase data
integrity but that costs some performance vs reiserfs and xfs that don't
have this extra protection)
2:24 a.m.
On Mon, 23 May 2005, Arjan van de Ven wrote:
On Sun, 2005-05-22 at 23:50 -0700, Dan Hollis wrote:
> On Mon, 23 May 2005, Arjan van de Ven wrote:
> > "linux jfs" isn't documented afaik.
> > The simple situation is that ext3 is basically all we really support and
> > test, the rest may or may not work. Is there a reason you want to use JFS ?
> > (ext3 in fc3/fc4 is pretty competative with any of the other filesystems on
> > just about every workload performance wise... the benchmarks I've seen
from
> > others hardly ever put JFS on top for anything nowadays so JFS strikes me as
> > a bit of an odd choice)
> xfs and reiserfs are _huge_ wins over ext3 for news servers.
1) Did you try this on 2.4 or 2.6? 2.6 ext3 (with htree and
reservations) is like a 3x improvement over the 2.4 ext3 in many
workloads and is sometimes even slightly better than reiserfs in the
"milions of files in a directory" scenario.
Both.
Its not just for large directories, reiserfs did much better with many
small files too (typical of news and mailservers). Note that reiserfs
wins _big_ in this case performance wise if you turn off tailmerging. In
my tests reiserfs lost vs ext3 on many-small-files-writing if you had
tailmerging on, but this was a tradeoff for ~10% or more extra storage
space you got from tailmerging.
2) Did you set the ext3 journalling mode to be on par with
reiserfs/xfs?
(By default ext3 uses a more strict journalling mode to increase data
integrity but that costs some performance vs reiserfs and xfs that don't
have this extra protection)
I tried all available ext3 journalling modes, it was never faster and
often many times slower.
But even with non-strict journaling we got some total filesystem
failures with ext3 where we did not with reiserfs and xfs on identical
systems with identical hardware and identical workloads.
We still have a few ext3 machines about but they are being phased out and
replaced with reiserfs as we get the chance.
-Dan
2:35 a.m.
On Mon, May 23, 2005 at 12:24:55AM -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
> On Sun, 2005-05-22 at 23:50 -0700, Dan Hollis wrote:
> > On Mon, 23 May 2005, Arjan van de Ven wrote:
> > > "linux jfs" isn't documented afaik.
> > > The simple situation is that ext3 is basically all we really support and
> > > test, the rest may or may not work. Is there a reason you want to use JFS
?
> > > (ext3 in fc3/fc4 is pretty competative with any of the other filesystems
on
> > > just about every workload performance wise... the benchmarks I've seen
from
> > > others hardly ever put JFS on top for anything nowadays so JFS strikes me
as
> > > a bit of an odd choice)
> > xfs and reiserfs are _huge_ wins over ext3 for news servers.
> 1) Did you try this on 2.4 or 2.6? 2.6 ext3 (with htree and
> reservations) is like a 3x improvement over the 2.4 ext3 in many
> workloads and is sometimes even slightly better than reiserfs in the
> "milions of files in a directory" scenario.
Both.
Its not just for large directories, reiserfs did much better with many
small files too (typical of news and mailservers).
Hmm. that surprises me for htree enabled filesystems (note that if you
create an FS with an old distro and then put 2.6 on it it doesn't use htree)
2:43 a.m.
Arjan van de Ven wrote:
...
Hmm. that surprises me for htree enabled filesystems (note that if
you
create an FS with an old distro and then put 2.6 on it it doesn't use htree)
How can I check if an ext3 filesystem uses htree?
Mogens
--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk(a)crc.dk Homepage: http://www.crc.dk
3:38 a.m.
On Mon, 23 May 2005, Mogens Kjaer wrote:
Arjan van de Ven wrote:
...
> Hmm. that surprises me for htree enabled filesystems (note that if you
> create an FS with an old distro and then put 2.6 on it it doesn't use
> htree)
>
How can I check if an ext3 filesystem uses htree?
dumpe2fs -h <partition> | grep features
If dir_index is in the list of filesystem features then htree is used.
- Panu -
4:09 a.m.
Panu Matilainen wrote:
...
dumpe2fs -h <partition> | grep features
If dir_index is in the list of filesystem features then htree is used.
Hm, most of my FC3 systems doesn't have this feature enabled.
I guess they have either been upgraded, or at some time
backed up & restored.
I'll fix this in rescue mode:
tune2fs -Odir_index <partition>
e2fsck -f -D <partition>
Wouldn't it be a good thing to include this
automatically during an upgrade?
Mogens
--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk(a)crc.dk Homepage: http://www.crc.dk
5:02 a.m.
On Mon, 23 May 2005, Arjan van de Ven wrote:
> Both.
> Its not just for large directories, reiserfs did much better with many
> small files too (typical of news and mailservers).
Hmm. that surprises me for htree enabled filesystems (note that if you
create an FS with an old distro and then put 2.6 on it it doesn't use htree)
Remember reiserfs was designed from the bottom up to work quickly with
lots of _small files_. So it does what it was designed to do well. That
this happens to be the typical workload of news servers and mailservers
is a happy coincidence.
Remember this is _not_ purely about directory sizes.
-Dan
5:05 a.m.
On Mon, May 23, 2005 at 03:02:23AM -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
> > Both.
> > Its not just for large directories, reiserfs did much better with many
> > small files too (typical of news and mailservers).
> Hmm. that surprises me for htree enabled filesystems (note that if you
> create an FS with an old distro and then put 2.6 on it it doesn't use htree)
Remember reiserfs was designed from the bottom up to work quickly with
lots of _small files_. So it does what it was designed to do well. That
this happens to be the typical workload of news servers and mailservers
is a happy coincidence.
yet a design goal leads to a technological implementation, and I'm wondering
what is a causing factor for ext3 to not be roughly equally fast. ext3 with
htree should in principle not be bad at lots of small files. at all. There
is no inherent bias in ext3 towards bigger files (well except when you count
not having tail merging; tail merging will give you gain in the case of a
read-mostly lots-of-small-files case)
5:22 a.m.
On Mon, 23 May 2005, Arjan van de Ven wrote:
On Mon, May 23, 2005 at 03:02:23AM -0700, Dan Hollis wrote:
> On Mon, 23 May 2005, Arjan van de Ven wrote:
> > > Both.
> > > Its not just for large directories, reiserfs did much better with many
> > > small files too (typical of news and mailservers).
> > Hmm. that surprises me for htree enabled filesystems (note that if you
> > create an FS with an old distro and then put 2.6 on it it doesn't use
htree)
> Remember reiserfs was designed from the bottom up to work quickly with
> lots of _small files_. So it does what it was designed to do well. That
> this happens to be the typical workload of news servers and mailservers
> is a happy coincidence.
yet a design goal leads to a technological implementation, and I'm wondering
what is a causing factor for ext3 to not be roughly equally fast. ext3 with
htree should in principle not be bad at lots of small files. at all. There
is no inherent bias in ext3 towards bigger files (well except when you count
not having tail merging; tail merging will give you gain in the case of a
read-mostly lots-of-small-files case)
I think some of this has to do with the fact that ext3 is fundamentally a
very, very, very old filesystem. Its some of the oldest code still in the
kernel iirc. Some of the assumptions made in the original design may no
longer be so relevant over a decade later. ext2 was in use when everyone
was still on PIO and C/H/S :-) reiserfs by comparison is brand spanking
new.
I recall hearing something about a tailmerging patch for ext2/3 somewhere.
What happened to that?
-Dan
5:30 a.m.
On Mon, May 23, 2005 at 03:22:37AM -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
> On Mon, May 23, 2005 at 03:02:23AM -0700, Dan Hollis wrote:
> > On Mon, 23 May 2005, Arjan van de Ven wrote:
> > > > Both.
> > > > Its not just for large directories, reiserfs did much better with
many
> > > > small files too (typical of news and mailservers).
> > > Hmm. that surprises me for htree enabled filesystems (note that if you
> > > create an FS with an old distro and then put 2.6 on it it doesn't use
htree)
> > Remember reiserfs was designed from the bottom up to work quickly with
> > lots of _small files_. So it does what it was designed to do well. That
> > this happens to be the typical workload of news servers and mailservers
> > is a happy coincidence.
> yet a design goal leads to a technological implementation, and I'm wondering
> what is a causing factor for ext3 to not be roughly equally fast. ext3 with
> htree should in principle not be bad at lots of small files. at all. There
> is no inherent bias in ext3 towards bigger files (well except when you count
> not having tail merging; tail merging will give you gain in the case of a
> read-mostly lots-of-small-files case)
I think some of this has to do with the fact that ext3 is fundamentally a
very, very, very old filesystem. Its some of the oldest code still in the
kernel iirc.
By no means true.
Some of the assumptions made in the original design may no
longer be so relevant over a decade later. ext2 was in use when everyone
was still on PIO and C/H/S :-)
actually that isn't the case. sure there was an ext2 way back. But it moved
forward quite a bit (htree is an example of that).
reiserfs by comparison is brand spanking
new.
reiserfs3 isn't so new though, it is like 6 years old. reiserfs4 is
entirely unrelated to reiserfs3.
The biggest difference between reiserfs3 and ext3 is that reiserfs3 is more
tree based on disk and ext3 uses blockgroups on disk. For directories they
nowadays both uses trees (since ext3 grew htrees). I haven't seen conclusive
evidence either way which is architectually better; trees tend to be a bit
more fragile but can do certain things better (but other things really poor,
if the tree has to rebalance all the time, in addition trees tend to cause
more fragementation longer term). Also there is a difference
between the on disk storage of metadata and the in memory one.
If you want to use reiserfs, by all means be my guest. Some people only
think they have performance gains with it, others really do. Reiserfs in
fedora tends to be "lightly tested" at best though, so make sure you test it
hard yourself before going into production.
5:58 a.m.
On Mon, 23 May 2005, Arjan van de Ven wrote:
If you want to use reiserfs, by all means be my guest. Some people
only
think they have performance gains with it, others really do. Reiserfs in
fedora tends to be "lightly tested" at best though, so make sure you test it
hard yourself before going into production.
For us its not a question of 'only thinking'. We actually tested it and
got clear performance wins.
We tested ext3, jfs, xfs, and reiserfs.
For us reiserfs is the clear winner for ISP workloads.
Its been heavily tested and works fine for us, thanks :-)
Our reiserfs results interested a business partner of ours who used
to swear by ext3. They also found out reiserfs was better all round for
them so they are also switching.
The only real caveat for reiserfs at the moment is the lack of selinux
support.
Oh yes, I also use reiserfs at home on the desktop with tailmerging
enabled. An extra 10% diskspace is significant especially when its 200gb
partitions :-)
-Dan
3:08 a.m.
On Monday 23 May 2005 20:58, Dan Hollis <goemon(a)anime.net> wrote:
On Mon, 23 May 2005, Arjan van de Ven wrote:
> If you want to use reiserfs, by all means be my guest. Some people only
> think they have performance gains with it, others really do. Reiserfs in
> fedora tends to be "lightly tested" at best though, so make sure you test
> it hard yourself before going into production.
For us its not a question of 'only thinking'. We actually tested it and
got clear performance wins.
We tested ext3, jfs, xfs, and reiserfs.
For us reiserfs is the clear winner for ISP workloads.
Does it work correctly as a root file system?
The following extract from reiserfsck(8) indicates that it won't:
--rebuild-tree
This option rebuilds the entire filesystem tree using leaf nodes
found on the device. Normally you only need this option if the
reiserfsck --check reports "Running with --rebuild-tree is
required". You are strongly encouraged to make a backup copy of
the whole partition before attempting the --rebuild-tree option.
Once reiserfsck --rebuild-tree is started it must finish its
work (and you should not interrupt it), otherwise the filesystem
will be left in the unmountable state to avoid subsequent data
corruptions.
Our reiserfs results interested a business partner of ours who used
to swear by ext3. They also found out reiserfs was better all round for
them so they are also switching.
Unless of course they want to do some common file system recovery options such
as putting an image of a file system on another file system. The last
reports were that if you put a Reiser3 image as a regular file in a Reiser3
file system then fsck would really mess things up.
The only real caveat for reiserfs at the moment is the lack of
selinux
support.
How is it lacking? In a quick test it seems to work.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
6:01 a.m.
On Wed, 25 May 2005, Russell Coker wrote:
On Monday 23 May 2005 20:58, Dan Hollis <goemon(a)anime.net>
wrote:
> For us reiserfs is the clear winner for ISP workloads.
Does it work correctly as a root file system?
Yes.
The following extract from reiserfsck(8) indicates that it
won't:
--rebuild-tree
This option rebuilds the entire filesystem tree using leaf nodes
found on the device. Normally you only need this option if the
reiserfsck --check reports "Running with --rebuild-tree is
required". You are strongly encouraged to make a backup copy of
the whole partition before attempting the --rebuild-tree option.
Once reiserfsck --rebuild-tree is started it must finish its
work (and you should not interrupt it), otherwise the filesystem
will be left in the unmountable state to avoid subsequent data
corruptions.
Why does that indicate reiserfs won't function as a root file system?
> Our reiserfs results interested a business partner of ours who
used
> to swear by ext3. They also found out reiserfs was better all round for
> them so they are also switching.
Unless of course they want to do some common file system recovery options such
as putting an image of a file system on another file system. The last
reports were that if you put a Reiser3 image as a regular file in a Reiser3
file system then fsck would really mess things up.
Er. This is true of _any_ journaled filesystem on top of an journaled
filesystem (xfs, jfs, and iirc ext3) due to bad interactions with linux's
caching. The general wisdom is to not do this, no matter what filesystem.
Alternatively you could put a reiser3 image on ext2 if you really want to
do that. It's not hard.
> The only real caveat for reiserfs at the moment is the lack of
selinux
> support.
How is it lacking? In a quick test it seems to work.
reiserfs (at least up to 2.6.11.10) doesnt have working support for
selinux attributes.
this is in fact a very well known problem[1]. though supposedly 2.6.12 is
supposed to fix this[2].
-Dan
[1]http://www.fedorafaq.org/#reiserjfs
[2]http://www.livejournal.com/users/james_morris/3580.html
7 a.m.
On Wednesday 25 May 2005 21:01, Dan Hollis <goemon(a)anime.net> wrote:
> The following extract from reiserfsck(8) indicates that it
won't:
> --rebuild-tree
> This option rebuilds the entire filesystem tree using leaf
> nodes found on the device. Normally you only need this option if the
> reiserfsck --check reports "Running with --rebuild-tree is
> required". You are strongly encouraged to make a backup copy of the
> whole partition before attempting the --rebuild-tree option. Once
> reiserfsck --rebuild-tree is started it must finish its work (and you
> should not interrupt it), otherwise the filesystem will be left in the
> unmountable state to avoid subsequent data corruptions.
Why does that indicate reiserfs won't function as a root file system?
When (not if) the root file system needs a thorough fsck any interruption
(such as power failure) will result in a non-bootable system.
But it's still a significant improvement, it used to be that --rebuild-tree
was not permitted on a ro mounted file system so booting from an install CD
was necessary to check the root fs.
> > Our reiserfs results interested a business partner of ours
who used
> > to swear by ext3. They also found out reiserfs was better all round for
> > them so they are also switching.
>
> Unless of course they want to do some common file system recovery options
> such as putting an image of a file system on another file system. The
> last reports were that if you put a Reiser3 image as a regular file in a
> Reiser3 file system then fsck would really mess things up.
Er. This is true of _any_ journaled filesystem on top of an journaled
filesystem (xfs, jfs, and iirc ext3) due to bad interactions with linux's
caching. The general wisdom is to not do this, no matter what filesystem.
No it's not. Put an ext3 image inside an ext3 file system and try to
reproduce the problem. You will discover that ext3 is not vulnerable to
this. Also try it on HPFS (non-journalled file system used by OS/2) and you
will discover similar problems.
It's nothing to do with journalling. It's a problem of recognising metadata,
file systems which have fixed locations for metadata have a much easier time
of this.
Alternatively you could put a reiser3 image on ext2 if you really
want to
do that. It's not hard.
Sure it's not hard. That's nice to know AFTER you've done it and had your
data corrupted (as has happened to several people).
This is also a security issue. For example you might be able to put a file in
your home directory which contains a ReiserFS image of a file system
containing a SUID file and then have a fsck make it a regular file owned by
root with the SUID bit set which would allow taking over the machine.
In a quick test I managed to create a SUID root file in such a manner, but it
seemed corrupted and could not be executed.
Hopefully Reiser4 will solve this issue.
> > The only real caveat for reiserfs at the moment is the lack
of selinux
> > support.
>
> How is it lacking? In a quick test it seems to work.
reiserfs (at least up to 2.6.11.10) doesnt have working support for
selinux attributes.
The latest rawhide kernel seems to have it. Did you do any tests?
Finally, are there still known situations where a corrupt ReiserFS file system
could corrupt kernel memory? This was the bug that got me to convert the
root file systems of machines I own to use Ext2/3.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
7:47 a.m.
On Wed, 25 May 2005, Russell Coker wrote:
On Wednesday 25 May 2005 21:01, Dan Hollis <goemon(a)anime.net>
wrote:
> Why does that indicate reiserfs won't function as a root file system?
When (not if) the root file system needs a thorough fsck any interruption
(such as power failure) will result in a non-bootable system.
But it's still a significant improvement, it used to be that --rebuild-tree
was not permitted on a ro mounted file system so booting from an install CD
was necessary to check the root fs.
Note that XFS won't let you fsck a readonly-mounted fs _at all_. Even a
non destructive read-only check. I've argued with the XFS developers
about this and they stated they don't see this as a problem and they're
not going to fix it. I have no idea why they think this is a good idea.
> Alternatively you could put a reiser3 image on ext2 if you
really want to
> do that. It's not hard.
Sure it's not hard. That's nice to know AFTER you've done it and had your
data corrupted (as has happened to several people).
Who?
> > > The only real caveat for reiserfs at the moment is the
lack of selinux
> > > support.
> > How is it lacking? In a quick test it seems to work.
> reiserfs (at least up to 2.6.11.10) doesnt have working support for
> selinux attributes.
The latest rawhide kernel seems to have it. Did you do any tests?
You mean FC4T3 installer has it? Or you mean the latest kernel
downloadable via yum updater?
Finally, are there still known situations where a corrupt ReiserFS
file system
could corrupt kernel memory? This was the bug that got me to convert the
root file systems of machines I own to use Ext2/3.
None that I know of. If there were you would expect them to be reported in
linux-kernel or bugzilla, and I don't see anything.
I do however see some serious recent issues with ext3:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149478
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139374
We can go around in circles endlessly posting tit-for-tat comparisons of
ext3 and reiserfs. Neither FS is flawless and both have their issues.
However reiserfs has been perfect for our needs in every way and in
production systems has shown zero failures whereas we had many total
losses with ext3.
-Dan
10:24 a.m.
On Wednesday 25 May 2005 22:47, Dan Hollis <goemon(a)anime.net> wrote:
> When (not if) the root file system needs a thorough fsck any
interruption
> (such as power failure) will result in a non-bootable system.
> But it's still a significant improvement, it used to be that
> --rebuild-tree was not permitted on a ro mounted file system so booting
> from an install CD was necessary to check the root fs.
Note that XFS won't let you fsck a readonly-mounted fs _at all_. Even a
non destructive read-only check. I've argued with the XFS developers
about this and they stated they don't see this as a problem and they're
not going to fix it. I have no idea why they think this is a good idea.
Interesting. I've got a couple of machines that can only boot with an XFS
root. Fortunately I can easily remove the disks from them.
> > Alternatively you could put a reiser3 image on ext2 if you
really want
> > to do that. It's not hard.
>
> Sure it's not hard. That's nice to know AFTER you've done it and had
> your data corrupted (as has happened to several people).
Who?
Me and Roger Wolff.
Just repeat the test I performed a few hours ago. Why are you so
argumentative about things which you can easily test? You don't have to
believe me, do your own tests and you'll get the same results.
> > reiserfs (at least up to 2.6.11.10) doesnt have working
support for
> > selinux attributes.
>
> The latest rawhide kernel seems to have it. Did you do any tests?
You mean FC4T3 installer has it? Or you mean the latest kernel
downloadable via yum updater?
2.6.11-1.1319_FC4 has it. As for FC4T3, that depends on the kernel, the
installer, etc. Why not test it?
Ext3 is the default file system for Fedora for reasons which have already been
explained. As the default choice Ext3 gets the most testing from Red Hat
employees, also Ext3 is a priority for testing as it's in RHEL. The purpose
of this list is for people from the community to assist us with testing, and
this particularly applies to non-default options. It would be good if you
could help us in this regard.
I'm sure that FC4 release will have a kernel at least as recent as
2.6.11-1.1319_FC4. So I don't expect any problems using ReiserFS and SE
Linux on FC4 release.
> Finally, are there still known situations where a corrupt
ReiserFS file
> system could corrupt kernel memory? This was the bug that got me to
> convert the root file systems of machines I own to use Ext2/3.
None that I know of. If there were you would expect them to be reported in
linux-kernel or bugzilla, and I don't see anything.
They were reported years ago on the ReiserFS list. Hans didn't seem inclined
to fix them as fixing such bugs incurred a performance penalty.
If that policy has changed in the ReiserFS development team then I'll write
some scripts to randomly corrupt ReiserFS file systems and try to reproduce
kernel bugs.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
1:18 p.m.
On Thu, 26 May 2005, Russell Coker wrote:
The purpose of this list is for people from the community to assist
us
with testing, and this particularly applies to non-default options. It
would be good if you could help us in this regard.
It would be nice if you would stop arguing against people using
non-default options then :-)
If you want things like reiserfs tested then stop arguing against people
using it :-)
-Dan
11:02 p.m.
On Thursday 26 May 2005 04:18, Dan Hollis <goemon(a)anime.net> wrote:
On Thu, 26 May 2005, Russell Coker wrote:
> The purpose of this list is for people from the community to assist us
> with testing, and this particularly applies to non-default options. It
> would be good if you could help us in this regard.
It would be nice if you would stop arguing against people using
non-default options then :-)
I am not making a blanket argument against ReiserFS. ReiserFS will work fine
for /var/spool/news or /var/spool/mail, also it has never had any SE Linux
issues for such use, there's the context= mount option and prior to that
people were using ReiserFS on SE Linux systems with genfscon entries in the
policy to give all ReiserFS files the desired context. One machine I ran had
ReiserFS used for /var/spool/squid and was configured such that all ReiserFS
files had the type squid_cache_t.
Also given the fsck issue, it's probably best to mount ReiserFS file systems
as nodev,nosuid.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:28 a.m.
On Wed, 2005-05-25 at 05:47 -0700, Dan Hollis wrote:
You mean FC4T3 installer has it? Or you mean the latest kernel
downloadable via yum updater?
FC4T3 kernel should have included the reiserfs xattr fixes to make it
work with SELinux, as the fixes were included in upstream kernels >=
2.6.12-rc1, and 2.6.12-rc1 was included in FC4 kernels a long time ago
(1.1187, 2005/03/18). For that matter, I would have expected it in
FC4T2 as well.
--
Stephen Smalley
National Security Agency
10:47 p.m.
On Wed, 25 May 2005, Stephen Smalley wrote:
On Wed, 2005-05-25 at 05:47 -0700, Dan Hollis wrote:
> You mean FC4T3 installer has it? Or you mean the latest kernel
> downloadable via yum updater?
FC4T3 kernel should have included the reiserfs xattr fixes to make it
work with SELinux, as the fixes were included in upstream kernels >=
2.6.12-rc1, and 2.6.12-rc1 was included in FC4 kernels a long time ago
(1.1187, 2005/03/18). For that matter, I would have expected it in
FC4T2 as well.
Nope, FC4T3 is busted and not only that, it won't be fixed:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159123
-Dan
10:55 p.m.
On Mon, May 30, 2005 at 08:47:53PM -0700, Dan Hollis wrote:
On Wed, 25 May 2005, Stephen Smalley wrote:
> On Wed, 2005-05-25 at 05:47 -0700, Dan Hollis wrote:
> > You mean FC4T3 installer has it? Or you mean the latest kernel
> > downloadable via yum updater?
> FC4T3 kernel should have included the reiserfs xattr fixes to make it
> work with SELinux, as the fixes were included in upstream kernels >=
> 2.6.12-rc1, and 2.6.12-rc1 was included in FC4 kernels a long time ago
> (1.1187, 2005/03/18). For that matter, I would have expected it in
> FC4T2 as well.
Nope, FC4T3 is busted and not only that, it won't be fixed:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159123
As with any unsupported component, you can file a bug in the
upstream bugzilla (bugzilla.kernel.org in this case), and Fedora
will inherit any fixes in a future update.
Dave
8:13 a.m.
On Mon, 2005-05-30 at 20:47 -0700, Dan Hollis wrote:
On Wed, 25 May 2005, Stephen Smalley wrote:
> On Wed, 2005-05-25 at 05:47 -0700, Dan Hollis wrote:
> > You mean FC4T3 installer has it? Or you mean the latest kernel
> > downloadable via yum updater?
> FC4T3 kernel should have included the reiserfs xattr fixes to make it
> work with SELinux, as the fixes were included in upstream kernels >=
> 2.6.12-rc1, and 2.6.12-rc1 was included in FC4 kernels a long time ago
> (1.1187, 2005/03/18). For that matter, I would have expected it in
> FC4T2 as well.
Nope, FC4T3 is busted and not only that, it won't be fixed:
No - just we don't spend any developer time in anaconda on it - if you
send patches for specific anaconda/Fedora reiser fixups then they'll get
considered for inclusion.
Paul
3:48 a.m.
On Wed, 25 May 2005, Russell Coker wrote:
On Wednesday 25 May 2005 21:01, Dan Hollis <goemon(a)anime.net>
wrote:
> > How is it lacking? In a quick test it seems to work.
> reiserfs (at least up to 2.6.11.10) doesnt have working support for
> selinux attributes.
The latest rawhide kernel seems to have it. Did you do any tests?
Yep I just finished testing.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159123
there you go, as you requested.
-Dan
7:48 a.m.
On Mon, May 23, 2005 at 03:22:37AM -0700, Dan Hollis wrote:
I think some of this has to do with the fact that ext3 is
fundamentally a
very, very, very old filesystem. Its some of the oldest code still in the
kernel iirc. Some of the assumptions made in the original design may no
longer be so relevant over a decade later. ext2 was in use when everyone
was still on PIO and C/H/S :-) reiserfs by comparison is brand spanking
new.
Not really. The fs has had major reworking over time and its one of the few
very SMP scalable file systems for example. Nor is it from the world of PIO and
C/H/S - it doesn't care about geometry and it threw out a lot of the old BSD
cruft like interleave and rotational latency tricks that were old world.
I recall hearing something about a tailmerging patch for ext2/3
somewhere.
What happened to that?
tailmerging is very 1980's, its not been worth deploying in the real world for
the past ten or more years. BSD FFS did big blocks on small disks in order to
get large block sizes to handle the lack of good command queueing and the
latency of block requests, and then needed the tail/fragment hacks to cover up
the space lossage. Nowdays nobody wants to trade 10-20% of performance for
1% more disk space given the price of disks and the disks can stream data at
high speed without 8K blocks.
Alan
8:37 a.m.
On Mon, 23 May 2005, Alan Cox wrote:
Nowdays nobody wants to trade 10-20% of performance for 1% more disk
space given the price of disks and the disks can stream data at high
speed without 8K blocks.
Alan self appointed spokesperson for the entire world :-)
At least on my home machine I got ~10% extra disk space and only take a
small performance hit on writes. Its like having a 220gb disk instead of
a 200gb one. Thats worth it to me at least.
And at least its an option for end users to choose, instead of "the one
and only true way" ala steve jobs applethink.
-Dan
2:09 a.m.
Hi
A pity selinux doesnt work on reiserfs yet, but selinux has serious
growing pains atm so we will wait for selinux to stabilize before we worry
about that.
There is a patch for reiserfs to support xattr but upstream isnt
interested. An explanation of the "growing pains" would also be useful
regards
Rahul
2:31 a.m.
On Mon, 23 May 2005, Rahul Sundaram wrote:
>A pity selinux doesnt work on reiserfs yet, but selinux has
serious
>growing pains atm so we will wait for selinux to stabilize before we worry
>about that.
There is a patch for reiserfs to support xattr but upstream isnt
interested. An explanation of the "growing pains" would also be useful
"not production ready" eg not ready for deployment in ISP production
environment. When people stop filing critical selinux bugs in buzilla then
it will be production ready :-)
And of course the lack of reiserfs support is a non starter for us too.
-Dan
4:03 a.m.
Hi
"not production ready" eg not ready for deployment in ISP
production
environment. When people stop filing critical selinux bugs in buzilla then
it will be production ready :-)
Using just the number of bug reports to assert whether something is
production ready or not looks like a bad idea to me. Take a look at the
bug count against any major package like the kernel or xorg for comparison
regards
Rahul
4:51 a.m.
On Mon, 23 May 2005, Rahul Sundaram wrote:
>"not production ready" eg not ready for deployment in
ISP production
>environment. When people stop filing critical selinux bugs in buzilla then
>it will be production ready :-)
Using just the number of bug reports to assert whether something is
production ready or not looks like a bad idea to me. Take a look at the
bug count against any major package like the kernel or xorg for comparison
I'm not using just the number. I'm using the criticality of the bugs. Eg
showstoppers.
Would _you_ seriously deploy FC4T3+selinux in a corporate production
server right now?
-Dan
4:54 a.m.
Hi
I'm not using just the number. I'm using the criticality of
the bugs. Eg
showstoppers.
Would _you_ seriously deploy FC4T3+selinux in a corporate production
server right now?
-Dan
It wasnt clear to me that you were talking about SELinux specifically in
the test releases. Test releases by design are not fit for production,
let alone SELinux in it. Of course I wouldnt suggest doing that
regards
Rahul
5:04 a.m.
On Mon, 23 May 2005, Rahul Sundaram wrote:
>I'm not using just the number. I'm using the criticality
of the bugs. Eg
>showstoppers.
>Would _you_ seriously deploy FC4T3+selinux in a corporate production
>server right now?
It wasnt clear to me that you were talking about SELinux specifically in
the test releases. Test releases by design are not fit for production,
let alone SELinux in it. Of course I wouldnt suggest doing that
Ok, would you recommend FC3+selinux in a corporate production environment
then?
-Dan
5:12 a.m.
On Mon, 2005-05-23 at 03:04 -0700, Dan Hollis wrote:
On Mon, 23 May 2005, Rahul Sundaram wrote:
> >I'm not using just the number. I'm using the criticality of the bugs. Eg
> >showstoppers.
> >Would _you_ seriously deploy FC4T3+selinux in a corporate production
> >server right now?
> It wasnt clear to me that you were talking about SELinux specifically in
> the test releases. Test releases by design are not fit for production,
> let alone SELinux in it. Of course I wouldnt suggest doing that
Ok, would you recommend FC3+selinux in a corporate production environment
then?
I'd not recommend FC<anything> in a corporate production environment,
I'd recommend RHEL for such environments.
(and yes RHEL4 has selinux enabled by default)
5:22 a.m.
Dan Hollis wrote:
On Mon, 23 May 2005, Rahul Sundaram wrote:
>>"not production ready" eg not ready for deployment in ISP production
>>environment. When people stop filing critical selinux bugs in buzilla then
>>it will be production ready :-)
>>
>>
>Using just the number of bug reports to assert whether something is
>production ready or not looks like a bad idea to me. Take a look at the
>bug count against any major package like the kernel or xorg for comparison
>
>
I'm not using just the number. I'm using the criticality of the bugs. Eg
showstoppers.
Would _you_ seriously deploy FC4T3+selinux in a corporate production
server right now?
good joke :-)
[...] not production ready [...] seriously deploy FCxTx+selinux in a
corporate production [...]
*
*http://www.net-security.org/search.php?sort=0&keyword=selinux&search.x=0&search.y=0
-> http://www.net-security.org/news.php?id=7755
->
http://searchenterpriselinux.techtarget.com/tip/0,289483,sid39_gci1082560...
<snip>
*"Think before deploying Security-Enhanced Linux in RHEL 4"
*One of the most exciting new features in RHEL v.4 is the implementation
of Security-Enhanced Linux (SELinux). In this tip, we'll look at how you
can use it to beef up system security.
</snip>
--
shrek-m
3:12 a.m.
On Monday 23 May 2005 17:31, Dan Hollis <goemon(a)anime.net> wrote:
On Mon, 23 May 2005, Rahul Sundaram wrote:
> >A pity selinux doesnt work on reiserfs yet, but selinux has serious
> >growing pains atm so we will wait for selinux to stabilize before we
> > worry about that.
>
> There is a patch for reiserfs to support xattr but upstream isnt
> interested. An explanation of the "growing pains" would also be useful
"not production ready" eg not ready for deployment in ISP production
environment. When people stop filing critical selinux bugs in buzilla then
it will be production ready :-)
SE Linux is enabled by default in RHEL4, it is a supported and recommended
feature.
I am not aware of any bugs reported against SE Linux that would make it
unsuitable for use in an ISP. I know of some ISPs that have it on their
servers.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
6:44 a.m.
On Wednesday 25 May 2005 21:02, Dan Hollis <goemon(a)anime.net> wrote:
On Wed, 25 May 2005, Russell Coker wrote:
> I am not aware of any bugs reported against SE Linux that would make it
> unsuitable for use in an ISP. I know of some ISPs that have it on their
> servers.
which isps?
I don't know of any that have given permission for such information to be
published.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
8:33 a.m.
On Mon, 2005-05-23 at 12:39 +0530, Rahul Sundaram wrote:
Hi
>
>A pity selinux doesnt work on reiserfs yet, but selinux has serious
>growing pains atm so we will wait for selinux to stabilize before we worry
>about that.
>
>
There is a patch for reiserfs to support xattr but upstream isnt
interested. An explanation of the "growing pains" would also be useful
Actually, reiserfs xattr support went upstream a while back, and fixes
to the reiserfs xattr support to allow use with SELinux are included in
kernels >= 2.6.12-rc1 (and thus in the FC4 kernels).
--
Stephen Smalley
National Security Agency
10:27 a.m.
On Sat, 2005-05-21 at 12:58 -0600, John P Poet wrote:
I have been happily running Fedora Core 2 for a year.
I just tried to install Fedora Core 4T3, but it fails with:
-------------------------------------
There was an error installing cracklib-dicts-2.8.2-1. This can
indicate media failure, lack of disk space, and/or hardware problems.
This is a fatal error and your install will be aborted.
-------------------------------------
If I switch over to F3, I see:
-------------------------------------
Setting file_context_path to /etc/selinux/targeted/contexts/file_contexts
-------------------------------------
F4 shows:
-------------------------------------
<6>SELinux: initialized (dev hda3, type xfs), uses xattr
<4>post_create: setxatter failed, rc=1 (dev=hda7 ino=16449)
-------------------------------------
My partion layout is:
hda1: /boot (ext3)
hda2: swap
hda3: /home (xfs)
hda4: extended
hda5: / (Fedora core 2) (ext3)
hda6: / (alternate root) (jfs)
hda7: / (Fedora core 4T3) (jfs)
I booted off the DVD with "linux jfs", so it would allow me to format
the root partion with jfs.
I told it not to install SELinux.
I did test the media, and it is fine. Pretty sure my hardware is
okay, since Fedora Core 2 is quite happy running on it.
Any other information I can provide to help track this problem down?
The errno displayed by post_create was EPERM. Looking at the jfs code,
it appears that they return EPERM from can_set_xattr() if the file is a
symlink. SELinux attempts to label all files, including symlinks.
Please report to the jfs maintainers, as it is a bug in their code.
--
Stephen Smalley
National Security Agency
6923
days inactive
6934
days old
46 comments
13 participants
participants (13)
-
Alan Cox -
Arjan van de Ven -
Dan Hollis -
Dave Jones -
John P Poet -
Mike Bird -
Mogens Kjaer -
Panu Matilainen -
Paul Nasrat -
Rahul Sundaram -
Russell Coker -
shrek-m＠gmx.de -
Stephen Smalley