Much faster? i18n? tls?
by Behdad Esfahbod
Hi,
Was tweaking with the grep patch, and also tracking another
thread in another list, which was showing how on Red Hat 9 a
simple text intensive program (called hspell) is much slower than
Red Hat 8, and investigations have shown so far that it's all
caused by /lib/tls. Switching to /lib/i686 makes things go much
faster. Any idea? And it's not a multi-threaded application.
So I focus on sed: Pretty slow on non-C locales:-(
[behdad@mces behdad]$ echo $LANG
en_US.UTF-8
[behdad@mces behdad]$ ll /bin/ls
-rwxr-xr-x 1 root root 73460 Oct 12 04:50 /bin/ls
[behdad@mces behdad]$ time sed -e 's/./x/g' /bin/ls > /dev/null
real 0m4.248s
user 0m3.800s
sys 0m0.000s
[behdad@mces behdad]$ time LANG=C sed -e 's/./x/g' /bin/ls > /dev/null
real 0m0.180s
user 0m0.050s
sys 0m0.000s
[behdad@mces behdad]$
And /bin/ls is only 72kb!!!
But you should have noticed that /bin/ls is not a valid UTF-8
piece. Actually /bin/ls is very small, if you run it on a bigger
piece of garbage (speaking encoding ofcourse), it's hard not to
get a SegFault. I have reported that here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109606
Any idea? May some one look if the same caching can be done
here?
behdad
20 years, 6 months
rpm 4.2.1-0.30 sleeps in futex system call
by Mike Snitzer
In attempting to import the Fedora GPG key with rpm 4.2.1-0.30 (from beta2
of FC) to upgrade to FC1; rpm goes to sleep in the futex system call.
...
open("/var/lib/rpm/Packages", O_RDWR|O_LARGEFILE) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=31690752, ...}) = 0
futex(0x406d0280, FUTEX_WAIT, 0, NULL <unfinished ...>
I am running 2.6.0-test9-mm1 and all has worked fine up until now; if I
attempt to shove the GPG key in there with:
LD_ASSUME_KERNEL=2.2.4 rpm --import fedora.RPM-GPG-KEY.txt
I get:
rpm: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory
so _really_ old pthreads libs (non-tls) don't offer librt.so (or a
compatibility symlink is missing?); but this did the trick:
LD_ASSUME_KERNEL=2.4.1 rpm --import fedora.RPM-GPG-KEY.txt
In any case, why might the futex system call get reliably wedged during an
rpm --import given that I'm using an nptl, futex, tls, enabled kernel?
Might an internal rpm lock be held?
thanks,
Mike
20 years, 6 months
ReiserFS in Anaconda?
by Ro
Is there or will it be support for ReiserFS in Disk Druid and the Kickstart
installation process? Is there documentation out there about this? I know I
can create ResiserFS partitions after the install is done.
Cheers,
Ro
20 years, 6 months
FC2 release dates
by seth vidal
Hi,
I think we should get an estimate on FC2 beta/freeze/release dates
ironed out right now.
If we're looking at 4-6 months how about:
Betas around Valentine's Day and St Patrick's Day:
Freeze for the second week of April
Maybe try for a release on Tax Day?
How does that sound.
Very holiday-centric.
-sv
20 years, 6 months
rawhide or fedora/development
by Farkas Levente
hi,
what is the current rpm directory for fedora's development packages?
- redhat's rawhide
- fedora/development
- or something else?
thanks.
--
Levente "Si vis pacem para bellum!"
20 years, 6 months
The Fedora Hardware Project
by Maxwell Kanat-Alexander
That's what I'm calling it for right now. Feel free to recommend any
name you desire.
The updated specification/summary for the project is up at:
<http://people.ucsc.edu/~maxka/fhp/>
I expect that to be a very temporary location -- the space may
disappear any day now.
Let me know if anybody else has any more ideas, now that we've got them
in a more manageable and organized form.
-M
20 years, 6 months
Re: Logrotating single-issue files
by Keith Lofstrom
Nicolas Mailhot writes:
> I'm battling with a few apps that create uniquely-named traces/logs in
> a logdir (typically using PID / date or a sequence number as a unique
> identifier). I naively though it might be possible to use logrotate to
> compress old traces and remove them after a while.
...
> Anyone got an idea ? Is the modified SuSE logrotate some people have
> been talking about able to cope with this ?
The SUSE modified logrotate takes an original and appends one date extension
(YYYYMMDD) then tosses it after a while. Not what you are dealing with.
Logrotate is probably not the proper tool. You may be able to use a pair
of "find ... exec ..." commands in a shell script called by cron to do
what you want. While you might build some ugly scripts and call them
from logrotate, the next maintainer will have no idea where the behavior
is coming from - logrotate is expected to do only certain things.
For example:
-----------------------------------------------------------------
#!/bin/bash
# /etc/cron.daily/myapp-log-maintainer
# compress all unused myapp log files of type A older than 2 days
find -atime 48 /var/log/myapp/logA* -exec gzip '{}' ';'
# delete all unused myapp log files of type A older than 2 weeks
# (plus the above 2 days)
find -atime 336 /var/log/myapp/logA*gz -exec rm -f '{}' ';'
#all done
exit 0
-----------------------------------------------------------------
This is untested, and I often get the -exec part wrong, use at your
own risk. I also tend to code the file paths as variables (for example,
MYAPPLOG=/var/log/myapp) and give full paths for executables in my own
shell scripts so I do not have to rely on possibly hacked PATHs, so
the example script should probably be modified those ways. You should
also put a README in the log/myapp directory telling future maintainers
what the heck is going on. You probably also want to log the fact
that this script was run in /var/log/messages.
You probably do not want to compress right away (hence the -atime). You
might actually be running the app making the log when cron starts up.
But you may be happy with "-atime 1" or something, where the log file
can get compressed only an hour after you stop actively looking at it.
Remember, you may still be running myapp when this script runs.
Lastly, if you have a nightly backup procedure called by cron.daily, you
probably want to call this first. And if you are using an rsync-based
disk backup procedure like I am, you do not want to modify the files at
all, or it causes just another copy (albeit compressed) to happen. Just
delete them when they get old to keep your directories uncluttered.
Keith
--
Keith Lofstrom keithl(a)ieee.org Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
20 years, 6 months
bugzilla for Fedora Core
by Gene C.
bugzilla has been set up with a Product name of Fedora Core and Versions 1,
test1, test2, and test3.
When Fedora Core 2 testing begins, I assume that there will be a test1, test2,
etc. Won't searches be confusing with (for example) test1 applying to bothe
FC-1 and FC-2?
For previous Public Betas, each beta had a unique name so which was used for
the Version identifier.
--
Gene
20 years, 6 months