Nicolas' Blog

It is with great happyness that I learned Ubuntu 14.04 was now trimming SSD by default. Wondering how it was done, I’ve started digging to find out how it was done.

The choice of the Ubuntu devs has been to go with a weekly cron job calling /sbin/fstrim-all, a bash script.

I wanted to trim right away and not wait for the next cron deadline so in a terminal I went ahead and ran a
sudo fstrim-all

To my great surprise, the script ran almost instantly, weird when you know a trim usually lasts a few minutes.

So I digged out my favorite text editor and read ahead. An extract follows:


HDPARM="`hdparm -I $REALDEV`" 2>/dev/null || continue
if [ -z "$NO_MODEL_CHECK" ]; then
if ! contains "$HDPARM" "Intel" && \
! contains "$HDPARM" "INTEL" && \
! contains "$HDPARM" "Samsung" && \
! contains "$HDPARM" "SAMSUNG" && \
! contains "$HDPARM" "OCZ" && \
! contains "$HDPARM" "SanDisk" && \
! contains "$HDPARM" "Patriot"; then
#echo "device $DEV is not a drive that is known-safe for trimming"
continue
fi
fi


So I rewinded a bit and read this “explanation” at the top of the file.


# As long as there are bugs like https://launchpad.net/bugs/1259829 we only run
# fstrim on Intel and Samsung drives; with --no-model-check it will run on all
# drives instead.
if [ "$1" = "--no-model-check" ]; then
NO_MODEL_CHECK=1
fi


So, what is happening is simple, either you have an Intel, a Samsung, a SanDisk, a Patriot or an OCZ SSD in which case the ext3, ext4, xfs and btrfs filesystems on the drive will be trimmed or you have another brand of SSD and Ubuntu wont trim it for you “yet”.

You can force the trim of course if you edit /etc/cron.weekly/fstrim and remplace the following

exec fstrim-all

Adding the –no-model-check flag to it:

exec fstrim-all --no-model-check

As most of the issues preventing generalized trimming happen under high I/O, my recommendation however is to run the trimming at a time you decide to do it (i.e. when you leave the machine idle for a while).

I’ve recently come accross an interesting problem while trying to use a cacti install running on a server located in Europe in order to monitor, generate and export statistics to be read by people in Central America. Indeed, the generated graphs indicated CET time while the people for whom the graphs were interested expected UTC-6 time.

While there has been a support request in cacti for this particular feature and I’ve come across a patch for 0.8.6 on cacti forums, I haven’t found a solution that is integrated into cacti. So I went for an external graph generation script.

Cacti generates graphs by invoking rrdtool which itself relies on the value of the TZ environment variable to determine the offset that it must apply to variables stored inside the database. Indeed, the time stored in an rrd is UTC by default and an offset is applied during graph generation in order to transpose this to any local time according to the value of the TZ variable.

The script I’ve created simply uses the command line I got from cacti by turning graph debugging on in the graph management for the particular graph I wanted to export.

TZ="America/El_Salvador" /usr/bin/rrdtool graph -
--imgformat=PNG --start=-86400 --end=-300
--title="My graph title" --base=1000 --height=120
--width=500 --alt-autoscale-max --lower-limit=0
--vertical-label="" --slope-mode --font TITLE:12:
--font AXIS:8: --font LEGEND:10: --font UNIT:8:
DEF:a="/var/lib/cacti/rra/my_file.rrd":somefield:AVERAGE
AREA:a#AFECEDFF:"" > somefield_1.png

The TZ=”America/El_Salvador” part of the command line redefines the value of the TZ environment variable before executing rrdtool. This modification is only local to the process from which rrdtool is launched and does not affect the current shell. The TZ variable is part of the zoneinfo package, the full list of possible values for this variable can be found under the /usr/share/zoneinfo directory of any linux machine.

--start=-604800 --end=-1800
--start=-2678400  --end=-7200
--start=-33053184  --end=-86400

MAILTO=myusername
*/5 * * * * www-data /path/to/myscript.sh >/dev/null 2>&1

Using this trick, I can now generate graphs that make sense to the people they’re intended for without asking them to perform the conversion from UTC by themselves.

The next ubuntu release, 10.04 is planned to be released on April 29th 2010. While the date is closing by rapidly, the development process is right on its track.

With a first beta release mid-March which allowed to spot some nasty bugs of all kind, the community is now working towards a second beta. Beta 2 is already past “freeze”, the point at which any additional change to the core packages of the distribution is subject to a process known as “freeze exception” for which good motivations must exist and thorough review is performed  by the release managers to make sure nothing that works is affected by the proposed change.

Needless to say, Lucid Lynx beta 2 will be a much more stable version with many bugfixes when its released on April 8th.

Areas in which you can still help at this points are:

• installing beta 2 and reporting bugs which are not yet reported or adding information to the existing report that might help track it down
• participating in the translation process through the translators groups until April 22nd.

The next step is to get a release candidate version on the 22nd for a final release of Lucid Lynx 10.04 LTS on April 29th! Get involved!

Mark Shuttleworth made the announcement a few days ago already that the next Ubuntu version will be named Lucid Lynx. It’s going to be an LTS which will superseed to the Hardy Heron and there will be a direct upgrade path from 8.04 as there always is between LTS releases. Lucid Lynx development will begin in November 2009 and the release is due in April 2010. However, Hardy will be supported through 2011 to allow for organization to upgrade in a smooth fashion!

Below is a video of Mark Shuttleworth who was in Atlanta at the time announcing, among other things, the codename and release goals.

As always with Ubuntu, things such as codename and release goals are defined by the community through discussion and white papers. All of this takes places between Launchpad.net, IRC and mailing lists as well as some quality websites, blogs and the community wiki.

[ad#Adsense-square]

After upgrading to Ubuntu Jaunty yesterday, I found that none of the pictures I had in F-Spot worked anymore. Ok, I have my pictures stored on a remote machine and I access them through SFTP but that shouldn’t be a reason for it to break so easily.

It appears that between Intrepid and Jaunty, the GVFS mounts done through the Places->Connect to Server… have changed mountpoint. Ideed, when they used to be mounted to /home/nicolas/.gvfs/sftp on someserver/ they are now mounted to /home/nicolas/.gvfs/sftp for nicolas on someserver/ and this broke F-Spot’s database.

In order to fix that, I went through the following:

1. Backed up /home/nicolas/.gnome2/f-spot in case I messed it up. 
2. sudo apt-get install sqlitebrowser 
3. sqlitebrowser /home/nicolas/.gnome2/f-spot/photos.db 
4. File-> Export -> Database to SQL file (data.sql in my case) 
5. Replaced all occurences of /home/nicolas/.gvfs/sftp on someserver/ 
with /home/nicolas/.gvfs/sftp for nicolas on someserver/ using 
a text editor

Removed two lines that would not allow me to restore the database:

CREATE TABLE sqlite_sequence(name,seq); 
INSERT INTO sqlite_sequence VALUES('photos',3306);

Restored the database:

sqlite3 -init data.sql data.db

Finally, overwrote photos.db with data.db

mv data.db photos.db

This fixed it and I got my photos back ;) In order to be able to import new photos however, I had to change the default location which was not found anymore as it still refered to /home/nicolas/.gvfs/sftp on someserver. This was done in the preferences window!

Happy F-Spotting