From Fedora Project Wiki

< FWN‎ | Beats

(pass 1 devel #174)
Line 35: Line 35:
 
A list of possible starting points to get more applications using preallocation was also provided.
 
A list of possible starting points to get more applications using preallocation was also provided.
  
In response to some skepticism from [[TomLane|Tom Lane]] further explanation of which sorts of applications might benefit from preallocation was shared<ref></ref> by Eric: "You wouldn't want to use it for every little file you write, either.  But for some cases it can be a big win.  Torrent downloading?  This is sort of the quintessential case where it can help.  Databases?  yes.  Rsyncing large files?  yep.  Creating virtual images? yep.  Helping samba cope with weird windows client behavior?  yep Basically anything that is filled in over time, or filled in sparsely, could potentially benefit." Further questioning by [[MichaelCronenworth|Michael Cronenworth]] on the value of using <code>ext4</code> as opposed to <code>xfs</code> yielded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02309.html</ref> further interesting details.
+
In response to some skepticism from [[TomLane|Tom Lane]] further explanation of which sorts of applications might benefit from preallocation was shared<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02281.html</ref> by Eric: "You wouldn't want to use it for every little file you write, either.  But for some cases it can be a big win.  Torrent downloading?  This is sort of the quintessential case where it can help.  Databases?  yes.  Rsyncing large files?  yep.  Creating virtual images? yep.  Helping samba cope with weird windows client behavior?  yep Basically anything that is filled in over time, or filled in sparsely, could potentially benefit." Further questioning by [[MichaelCronenworth|Michael Cronenworth]] on the value of using <code>ext4</code> as opposed to <code>xfs</code> yielded<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02309.html</ref> further interesting details.
  
 
It seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02285.html</ref> that the <code>libvirt</code> developers had already jumped at the opportunity thanks to a patch provided<ref>http://www.amitshah.net/2009/03/comparison-of-file-systems-and-speeding.html</ref> by Amit Shah.
 
It seemed<ref>http://www.redhat.com/archives/fedora-devel-list/2009-April/msg02285.html</ref> that the <code>libvirt</code> developers had already jumped at the opportunity thanks to a patch provided<ref>http://www.amitshah.net/2009/03/comparison-of-file-systems-and-speeding.html</ref> by Amit Shah.

Revision as of 11:55, 4 May 2009

Developments

In this section the people, personalities and debates on the @fedora-devel mailing list are summarized.

Contributing Writer: Oisin Feeley

Fedora 11 Preview Xorg "Lock-up"

DrDiesel reported[1] an Xorg lockup with a fully updated Fedora 11 Preview on 2009-04-28 whenever he visited a particular webpage. Subsequent confirmation from other testers led[2] to a bugzilla report. It intially appeared to be a soft lock according to some comments on the bug which reported the ability to move the mouse cursor and play music.

Some very helpful contributions from Adam Jackson suggested[3] that the problem was due to a ridiculously large blit[4] exposing mis-handling of video memory mapping by the kernel. Adam laid[5] the blame squarely on the mis-coding of the web-page. He added that this was not actually a lock-up, just agonizingly slow rendering. RichardKörber requested further help in debugging this and similar problems and that request led[6] to a nice, succinct recipe for generating gdb backtraces.

Presto No Go

Unfortunately it appears that Presto, the near miraculous bandwidth saving YUM plugin[1], will not be an official part of Fedora 11 due to infrastructure issues cited[2] by Paul W. Frields. This is contrary to what we reported[3] in FWN#172.

Fedora 12 Changes to GConf and intltool

Matthias Clasen requested[1] feedback on changes in the way sechma translations were handled in GConf and intltool: ly, translations were merged by intltool from .po files into schemas files and then copied by gconftool from the schemas file into the database. Now, translations are kept in .po files, and intltool only copies the gettext domain into the schemas, and further into the GConf database. The only tool that ever uses these translations, gconf-editor, knows how to get them from the message catalogs. The big advantage of this change is that schemas shrink radically, which should help a lot with the 'slow updates due to GConf' problem. It also reduces the redundancy of storing the schema translations in three places, which should help with live cd size."

It seemed[2] that all GConf-using applications will be rebuilt before Fedora 12 ships but that there is no immediate rush to do so.

Ext4 fallocate() Happiness

[[EricSandeen|Eric Sandeen] suggested[1] that it would be useful to speed the adoption of the preallocation features of the ext4 filesystem. (See FWN#170[2] for previous coverage.) Eric provided a concise, informative description of what preallocation is and how it can be used: "One big feature that has already been brought up on the list[1] is file preallocation, which allows an application to pre-allocate blocks it knows that it will eventually write into, thereby making sure it won't run out of space, and also generally getting a more efficient/contiguous file layout. Only a few applications are taking advantage of this so far, in part because it's new.[2] The transmission bittorrent client is using it, but only if you tweak a configfile in (IMHO) non-obvious ways."

A list of possible starting points to get more applications using preallocation was also provided.

In response to some skepticism from Tom Lane further explanation of which sorts of applications might benefit from preallocation was shared[3] by Eric: "You wouldn't want to use it for every little file you write, either. But for some cases it can be a big win. Torrent downloading? This is sort of the quintessential case where it can help. Databases? yes. Rsyncing large files? yep. Creating virtual images? yep. Helping samba cope with weird windows client behavior? yep Basically anything that is filled in over time, or filled in sparsely, could potentially benefit." Further questioning by Michael Cronenworth on the value of using ext4 as opposed to xfs yielded[4] further interesting details.

It seemed[5] that the libvirt developers had already jumped at the opportunity thanks to a patch provided[6] by Amit Shah.

NetworkManager in Fedora 11 Preview

MarkBidewell wondered[1] why his sole network interface was inactivated automatically following a fresh install of Fedora 11 Preview.

DanWilliams explained[2] that this was a logical result of anaconda writing either

"ONBOOT=no"

if the install was not over a network or else

"ONBOOT=yes"

if the install was over a network. Dan explained that this was in part a security policy decision. Later Dan suggested[3] using nm-connection-editor to correctly

/etc/sysconfig/network-scripts/ifcfg-*

for both wired and wireless connections.

Moblin2 Mostly Fedora-derived ?

Matthew Garrett picked up[1] on an older discussion about the extent to which Moblin2 could be considered a derivative of Fedora. Matthew's conclusion was that most of the packages were "[...] identical to the Fedora package or is a simple mechanical transformation of a Fedora package[.]" A significant number of the patches were mostly derived from Fedora or SuSE also.

Fedora 12: How to use DBUS for Terminal Sessions ?

Dan Walsh asked[1] for help in running a dbus session upon login to terminals so that he could run restorecond as a system service rather than a user service: "I want to run it under the Users UID and under with the users context. Then I can have it watch for creation of files in the users home directory and be the equivalent of running restorecon ~/ by the user."

Steve Grubb was[2] worried that this would disrupt the audit trail and suggested a PAM session module instead. Bruno Wolff III also was disturbed[3] by the idea: "This seems to increase the risk of hostile apps being able to get executables relabelled to something they couldn't do directly."

PulseAudio Flamewar Continues

The fallout from last week's thermonuclear flamewar continued[1] to splatter downwards. Among the hotspots were: a thread in which Johan B. Gudmundsson suggested[2] some way in which there would be no privileged default desktop spin;

Bill Nottingham argued[3] that slamming the PulseAudio team for closing bugs WONTFIX was inaccurate.

It seems that perhaps pavucontrol may be one way to change the relative volume of individual applications (as per a question posed my Matthew Woehlke and echoed[4] by Paul W. Frields. Lennart Poettering stated[5], however, that pavucontrol should be removed.