Posted by rawhidewatch on April 20, 2009
yum-presto in rawhide now is in need of widespread testing. Presto allows yum to download Delta RPM .drpm files, which contain only the difference between your installed package and the upgraded new version. This allows yum to update packages with significant download bandwidth and time savings.
Please help us verify that yum-presto is working properly. Please test it with both standard yum command line and PackageKit. Simply run yum install yum-presto. No further configurations are necessary. Please report any problems to Bugzilla.
Posted in Uncategorized | Comments Off on yum-presto Delta RPM support needs testing
Posted by rawhidewatch on April 17, 2009
In the past week I’ve noticed the following strange behavior on multiple Rawhide machines.
- I am logged into the GNOME desktop.
- I select System > Shutdown > Shutdown
- X dies, the shutdown animation happens, but it just stops.
- Ctrl-Alt-F2 switches to a VT, but typing does nothing because the getty is dead.
- Ctrl-Alt-Delete starts the reboot process, where we see things actually go through the shutdown process with services stopping.
Shutdown from GDM, or shutdown immediately after logging into GNOME do not exhibit this behavior. I am told that Bug #495326 is related to this issue.
Posted in Uncategorized | Comments Off on GNOME > System > Shutdown fails to Shutdown?
Posted by rawhidewatch on April 13, 2009
Many early SSD owners paid hundreds of dollars for a solid state drive disk, only to realize that performance is terrible with “stuttering” caused by terrible SSD controllers made by JMicron and its inability to handle random write patterns. Intel’s X25-M and 25-E drives have consistently beat all other consumer grade SSD drives due to its superbly designed SSD controller, but at a huge price premium. Generally users of Intel’s SSD’s have avoided the “stuttering” problems of lesser quality drives.
Unfortunately, it seems that 15-60 seconds of seemingly deadlock-like non-responsiveness can happen even with an Intel X25-M when using ext4 filesystem. Ever since I upgraded my Thinkpad T60 laptop to an Intel X25-M 160GB drive, my entire system would feel like it freezed, but then I notice the hard drive light flashing intermittently. After maybe 30-60 seconds the hard drive light would be solid on for a few seconds, then the system would recover. I cannot figure out how to reproduce this on-demand, but it seems to happen 2-3 times a day, and only during times where disk activity is very low.
In any case, this problem goes away entirely if I add “nodelalloc” to the mount flags of my ext4 filesystems. This turns off ext4 delayed allocation, which can typically delay writing to the disk for longer periods than ext3’s 5 seconds, perhaps 30-60 seconds. This is a benefit to hard drives because you can save power by spinning up less often. But for Intel”s X25-M drives, you are better off writing as early and often as possible since the drive doesn’t spin (no power benefit), and it reportedly handles parallelism internally very well, meaning the OS shouldn’t worry about it because there is no performance benefit.
In related news, it was suggested to me that elevator=noop is useful in your kernel cmdline in grub.conf if your disks are SSD. While I am personally trying it, I am uncertain if this is a good thing. While the elevator normally wouldn’t be necessary with a theoretically perfect solid state disk with constant-time random access to any address, SSD’s are not perfect with constant time access. Especially in the case of writing many small changes to non-contiguous parts of the disk, SSD’s suffer from what is known as write amplification because SSD’s need to read, erase and re-write entire blocks if you change only a tiny portion of that block. I wonder if write-combining that happens in the elevator prevents a few I/O writes to non-adjacent but nearby blocks from triggering multiple write events to the same SSD block. If it turns out the elevator does help to minimize write amplification before it gets to the SSD’s controller, then it would be both a performance benefit as well as helping the longevity of the disk. I have no clue how to measure this. Perhaps we need Intel engineers + people who know filesystems to answer this.
In any case, this ext4 behavior with Intel X25-M seems to be a bug in ext4? I don’t know.
Jeff Moyer pointed out that recent versions of the CFQ elevator has smart SSD detection. If SSD is detected, it disables idling during random access reads because the penalty for reading is not severe. He thinks you are better off using the default CFQ scheduler with these drives. Jeff also pointed out that elevator=noop will also do write combining.
UPDATE April 17th,2009:
Intel released a firmware update for their X25-M and X18-M SSD’s that improves performance in the worst case scenario. I flashed my X25-M and turned off nodelalloc to see if this makes a difference. It seems ext4 still behaves badly without nodelalloc with occasional episodes of 15-60 seconds of unresponsiveness.
Posted in Uncategorized | Comments Off on ext4 on Intel X25-M SSD needs nodelalloc
Posted by rawhidewatch on April 10, 2009
F-11 rawhide users might have noticed weird behaviors with video playing in the past months. Playing videos in Youtube, mplayer or totem would often play with audio immediately, but you see no video for a few seconds. Then suddenly many video frames rapidly play, then video becomes smooth in sync with the audio. It turns out that this was actually problems with video syncing to the audio clock of pulseaudio. The latest build pulseaudio-0.9.15-9+ substantially improves this weird problem at the beginning of videos, and seems to make video playback smoother as well. Note that if you are using mplayer, you need this patch to be applied to remove a workaround hack, otherwise you might not notice any improvement. Hopefully distributors of mplayer will patch soon.
Posted in Uncategorized | 1 Comment »
Posted by rawhidewatch on April 8, 2009
Some rawhide x86_64 users have hit a problem where firefox and rpm were broken by a dependency problem. Adam Williamson wrote:
The nss-184.108.40.206.3-5 package introduced a dependency on nss-softokn-freebl. However, this dependency was not architecture specific: it could be satisfied by the i586 or x86-64 package. Depending on what packages they had installed, x86-64 users could wind up with only the i586 nss-softokn-freebl package, which broke nss, and – in consequence – at least Firefox and also rpm.
The nss-220.127.116.11.3-7 update fixes this by making the dependency arch-specific. If you have been affected by the issue – you’ll know if
you’re running x86-64 Rawhide and your Firefox and rpm don’t work, and you can verify by checking what nss-softokn-freebl packages are installed – you can get out of the jam by downloading the x86-64 nss, nss-tools and nss-softokn-freebl packages from a Rawhide mirror and running:
rpm2cpio PATH_TO_RPM/nss-18.104.22.168.3-7.fc11.`uname -m`.rpm | cpio -i
rpm2cpio PATH_TO_RPM/nss-softokn-freebl-22.214.171.124.3-7.fc11.`uname -m`.rpm | cpio -i
rpm2cpio PATH_TO_RPM/nss-tools-126.96.36.199.3-7.fc11.`uname -m`.rpm | cpio -i
Posted in Uncategorized | Comments Off on Rawhide x86_64 firefox and rpm broke? Workaround Procedure