> Will this hit a system with EXT3->LVM->MDRAID1 particularly hard? Took
> about two hours to do a local install (with a largish set of packages
> but not everything) which I seem to remember took about 3/4 of an hour
> During installation ext3_xattr_block_set and r1bio_pool_alloc show as
> the top guzzlers, totalling 1.5 billion allocations between them,
> obviously plenty of disk writing going on ...
long running application doing enet to disk transfer sustains
2.6mbytes/sec transfer with 20% cpu busy (mostly non-kernel time).
post-1788 kernel, it is 100% cpu (mostly kernel time) and 600kbytes/sec
sustained (an increase of over 20times in total cpu executed per byte
transferred and possibly an increase of 100times in kernel cpu executed
per byte transferred).
Since about mkinitrd-5.0.11, software raidsets are being created in /dev
during initrd with the name /dev/md_dn where n is the number of the
raidset instead of /dev/mdn. This is causing all sorts of problems from
the worst being kernel panics and the least being raidsets not being
mounted in fstab.
Does anyone know why this is happening and does it mean we have to make
some changes to the way we use raid?
My /usr/share/doc/HTML/index.html is still the old Core 4 release notes even
though I am running current rawhide release. Is there some package I can
install to update all the documentation to core 5 or does that take a fresh
When I install non-Fedora RPMs I get:
error: %post(rpmname-n.n-n) scriptlet failed, exit status 255
Where rpmname is the RPM (e.g. W3C's Amaya, Real Player, etc.).
This seems to break the end of the install: the normal symlinks are
missing in the bin directory.
Is this a bug?
dell poweredge 2400 dual 1ghz processors. (at least smp) kernels after
1788 have enormous kernel processor overhead.
applications that are i/o bound on kernel 1788 or earlier ... are
severely degraded on kernels after 1788 with 100% processor utilization
... almost all of it in kernel. when applications are idle ... the
processor use goes idle (aka it isn't some sort of background looping
process ... but seems to be some sort extra kernel overhead).
this is machine that i had problems with scsi i/o hanging after fc4 smp
kernel 1278 (non-smp kernel didn't have scsi i/o hang problem). smp
kernel hanging problem cleared up with fresh fc5 install.
Fresh rawhide install this morning...
Anyone still experiencing gnome-terminal crashing when you open more
than one instance?
Also, I noticed that when opening Nautilus and you copy a file/dir,
paste it into a folder, and if it needs to overwrite something, it
"It's only funny until someone gets hurt, then it's hilarious!"