rgrunber

Reducing disk I/O with profile-sync-daemon

A little while ago, I finally got a new laptop! After 8 years with a Dell Inspiron 6400 (that has served admirably), I decided on a Dell XPS 13 9333. Fedora 20 worked without any major tweaking. I basically just needed nomodeset on the livecd to get the display working properly, but after a full update, even that wasn’t necessary. Did I mention the touch screen works as well ?

With 8 GB of memory and a 256 GB SSD, it’s already a pretty fast machine, but I’m still trying to optimize performance, and improve battery life, making compromises where necessary. Aside from tuning some kernel parameters, and filesystem options, I’ve come across profile-sync-daemon . It’s a nice tool specifically designed to reduce the disk I/O on a web browser’s profile by ensuring all changes are mainly done in memory (tmpfs) and written back to disk at a later time. It’s also quite easy to set up.

$ yum -y install profile-sync-daemon

Next, simply edit ‘/etc/psd.conf’ and set USERS to contain the list of users the daemon should act upon, along with the list of BROWSERS to manage.

You can even parse the configuration to confirm you’ve set it correctly :

$ profile-sync-daemon parse
Profile-sync-daemon v5.45.1 on Fedora release 20 (Heisenbug).

 Systemd service is currently inactive.
 Systemd resync service is currently inactive.

Psd will manage the following per /etc/psd.conf settings:

 browser/psname:  firefox/firefox
 owner/group id:  user/1000
 sync target:     /home/user/.mozilla/firefox/w74lprxm.default-1408456117113
 tmpfs dir:       /tmp/user-firefox-w74lprxm.default-1408456117113
 profile size:    22M

Now just make sure you’ve temporarily closed any browsers that will be affected by the daemon in order to call :

$ systemctl start psd.service
$ systemctl enable psd.service

and you’re good to go.

As it turns out profile-sync-daemon mainly exists to handle some special cases that are specific to browser profiles. However there’s also anything-sync-daemon that may be used for .. everything else. I have Eclipse open quite often so having things like the $HOME/.eclipse folder or even certain workspace metadata locations (workspace/.metadata/.mylyn) moved into tmpfs might prove useful.

No bug left unassigned

There’s something really satisfying about resolving and (especially) closing a ~2.5 year old bug. In this case it wasn’t a new feature or bug, but just better compliance with packaging guidelines regarding bundled libraries. Thanks to all those that helped out!

Extending the p2 Repository Format in Fedora

We ship a lot of OSGi bundles in Fedora.

$ repoquery --repofrompath=foo,http://kojipkgs.fedoraproject.org/repos/f21-build/latest/x86_64/ --repoid=foo -q --whatprovides "osgi(*)" | wc -l
693

We already allow packagers to have requirements based on the OSGi metadata to some extent. We’re supporting Require-Bundle in specfiles through use of the “osgi(…)” provide but even with this, building Eclipse plugins has always seemed like a giant hack, and even more so when compared to the latest Java Maven Packaging Examples. Building with Tycho requires that your OSGi dependencies be in a p2 repository (update site). We obviously can’t just point to the eclipse.org update sites for our Fedora builds since all of our dependencies must be from packages within the Fedora infrastructure that were built from sources. Initially the simplest way to achieve this was to look on the system for all OSGi bundles, publish them to a p2 repository, and then feed this directly into Tycho’s build target platform.

This approach certainly works (and that’s what the copy-platform-all script did) but it still requires performing the same steps every time one needs to feed OSGi bundles to Tycho or some other application that uses p2 repositories. The end-goal is to have tighter integration with tools like XMvn, and to make packaging an easier task. To do this we really need to have our system locations be recognized as p2 repositories so that we could also take advantage of p2 APIs.

When I got back from EclipseCon NA 2014, I started playing around with this idea of having filesystem directories being recognized as a p2 repository.

Imagine :

$ eclipse -application org.eclipse.equinox.p2.director -repository fedora:/usr/share/java/ -installIU org.swtchart

with the result being that ‘org.swtchart’ from somewhere in ‘/usr/share/java’ gets installed into the eclipse instance. This was easy to implement and fairly simple to integrate with Tycho so that we only inject a few system locations and get proper dependency resolution.

I’ve named this fedoraproject-p2 mainly because Fedora’s requirements are the driving force but I could see this being useful in many other cases.

This has been used for some time now on rawhide, and with the addition of things like the xmvn-p2-installer-plugin, it won’t be long until Eclipse plugin packaging will be drastically simpler.

Follow

Get every new post delivered to your Inbox.