2012-09-30

Linux filesystems for simple storage

Newly bought USB keys or memory cards usually come with patent-encumbered FAT or exFAT filesystems on them. While exFAT does away with size limitations, it is still not a first-class citizen under Linux. Only a fuse-based solution is available for mounting so far, which is not even in repositories such as rpmfusion due to the licensing issues.

If the volumes aren't to be used in devices such as digital cameras or PVRs, and use in Windows-PCs is also not an issue, one can of course opt for a native Linux filesystem.
However, standard mkfs.extX will use a lot of space for some things that is well-spent on a large system harddrive, but much less so on a relatively small flash device.

So here are two commands to make neat little filesystems for these:
mkfs.ext2 -T largefile -m 0 -L <some_name> /dev/sdX1
tune2fs -c 0 -i 0 -O large_file /dev/sdX1
Choosing mkfs.ext2 will result in maximum usable capacity. However it will not create a journal like ext3 / ext4 would. A journal does away with lengthy filesystem checks in case the medium was not properly unmounted. Given that today's USB keys provide multi-gigabytes of storage and that Linux tends not to mount such devices in synchronous mode by default, you may still choose to keep the journal for removable media. Extents are actually a nice thing that can save space for large files, but it is a relatively new feature that should be avoided for portable media at the moment so they can also be used with older Linux versions, YMMV.

The -T largefile option gives a better ratio of space reserved for management structures vs. actual data to be stored. Assuming you will usually not store thousands of files with only a dozend bytes in them this makes sense, but don't try this with an unpacked gentoo portage tree!

The large_file flag is normally set automatically and allows storing files >2GiB on the filesystem.

The -m 0 flag makes sure there is no space set aside for the superuser, which would make no sense on a data-only volume.

The -c 0 -i 0 flags prevent the filesystem from asking to be checked from time to time. This normally just puts warnings in your logs; no system I'm aware of runs fsck on hotplugged storage devices, and hardly anyone checks their USB keys manually as far as I can tell.

Getting the serial number of a certificate stored in pkcs12

When saving a client certificate from a Mozilla application to disk – like getting it out initially after it's been installed from the cacert website – the certificate is inside a PKCS12 container.

To uniquely identify a certificate, it is useful to know its serial number, especially if you have several certificates that are similar and have gotten renewed several times, so there is more than one version of "the same" certificate around.

To learn the serial number from a p12 file, I use this line:
openssl pkcs12 -in <container>.p12 -clcerts -passout pass:"" | openssl x509 -serial -noout
Usually the certificate will be encrypted, so you have to type in the password that was used on export.