2012-03-20

Running ExtraDB on a Linux block device

Since the future of free MySQL appears a bit uncertain due to the fact that its owner happens to be well recognized for its self-developed proprietary database, I decided to have a look at the fork that is led by the original main developer of MySQL: MariaDB.

Interestingly, things have not changed much once you get your head around the fact that the database itself as well as the engines have been renamed in the documentation, but still use their familiar names in the config files.

So the state-of-the-art storage engine that used to to be InnoDB is now called ExtraDB, but all its config options still start out with innodb_. Also the engine names in table type specifications still use the old names. So mostly, you just replace MySQL with MariaDB and keep going.

There is one catch however when using a raw block device for ExtraDB tablespace: It no longer works to pass the absolute name of the block device's /dev file (eg. /dev/sdb1). Examining mysqld.err reveals that the daemon actually tried to access a file by the name .//dev/sdb1, which looks to me like somebody took Windows support quite a bit too far.

120116 15:21:21  InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
InnoDB: If you are installing InnoDB, remember that you must create
InnoDB: directories yourself, InnoDB does not create them.
InnoDB: File name .//dev/sdb1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.

Fortunately there is a simple workaround for this bug, simply create a symlink or a replica of the respective device node inside the /var/lib/mysql directory and point the daemon to plain sdb1.

cp -a /dev/sdb1 /var/lib/mysql/


/etc/mysql/my.cnf:
innodb_data_file_path           = sdb1:10000269312raw





2012-03-11

Bulk-shrink images with ImageMagick

I'm one of those (apparently few) people that are annoyed by emails showing me e.g. the location of a screw on a piece of metal with 3 pictures of 2 Megabytes each.

So as I'm trying to lead by example (uber-smug, ain't I?), when sending pictures I took with a digital camera myself I reduce those images to around 600 pixels along their larger dimension, which will do nicely in most cases and save the other party the trouble not only of downloading huge files but also of staring at a tiny irrelevant detail of the picture that happens to be in the top left corner after the image viewer has ceased up their entire screen.

The best interactive tool for the occasional view-crop-correct-resize-compress task is obviously gthumb, but when faced with a larger number of images, it's commandline-time:

mogrify -quality 82 -resize 600x600\> *.jpg

This will shrink all jpg files in the current directory to fit within a 600x600 pixel bounding box while preserving aspect ratio (so the images are not distorted as one might first think). The closing angle bracket at the end ensures that images that are smaller than the target size are not enlarged. Note that the mogrify command changes the images in place, so you may either want to make sure to have a backup of the original files, or go for find/convert instead.
For more information, here is the resize operator's official documentation.

Another little-known but very excellent feature of the ImageMagick suite is the -strip operator, which will remove all EXIF data from an image. This can be useful especially when the picture was taken on a modern smartphone which will normally embed all sorts of information in the image's metadata such as location and time of the shot, as well as the model name of the device the image was taken with. Maybe you wouldn't want to share that with everyone that should see the picture.