wipefs(8)

This new command from util-linux-ng-2.17 is user friendly solution for people who have block devices with more valid filesystem signatures.

It's usually mkfs bug when old signatures are not removed from the device. The situation when you have more signatures on the device could be pretty dangerous. For example you can call swapon(8) for a wrong device and lost your data (see fedora bug #473514).

The libblkid was fixed few months ago and it does not return ambivalent information now. All devices with more signatures are ignored (well, there is exception for RAIDs, volume managers and some special filesystems like iso9660 and UDF). The blkid(8) command returns:

# blkid -p /dev/loop0
/dev/loop0: ambivalent result (probably more filesystems on the device)

Now imagine that you have data on the device, what next?

Use dd(1) and hexdump(1)... well that's joke :-) Use wipefs(8) and remove old (unwanted) filesystem signature.

The command without any option lists details about all detected filesystems:

# wipefs /dev/loop0
offset               type
----------------------------------------------------------------
0xff6                swap   [other]
                     UUID:  da6c54ea-77d9-470a-82f1-e793fd5d9131

0x36                 vfat   [filesystem]
                     UUID:  497F-3013

Now remove unwanted swap signature:

# wipefs --offset 0xff6  /dev/loop0
10 bytes [53 57 41 50 53 50 41 43 45 32] erased at offset 0xff6 (swap)

The wipefs(8) command does not erase whole filesystem superblock or so. It removes magic strings only. Now the device is useful for blkid(8):

# blkid -p /dev/loop0
/dev/loop0: SEC_TYPE="msdos" UUID="497F-3013" VERSION="FAT12" TYPE="vfat" USAGE="filesystem"

The other change in util-linux-ng-2.17 is that detailed information about ambivalent probing results are reported to udevd ($ID_FS_AMBIVALEN variable) so it will be possible to notify users by UI (e.g. Palimpsest).

libblkid

I think I can say that filesystem probing (identification) code in Linux distributions has been successfully consolidated to the one library. The libblkid.

The library is Ted Tso's baby and was maintained and distributed within e2fsprogs package for many years. Unfortunately, the library didn't match with udev requirements. The udev project requires lightweight probing library without any high-level logic. This was reason why udev developers created a new probing library -- libvolume_id.

And finally and unfortunately there was very old filesystem probing code in the mount(8) utility too. The useless code in mount(8) was ignored by mainstream Linux distributions (for example Suse linked their utils against libvolume_id and RHEL/Fedora against libblkid) .... and this is not end of nightmare.

The other filesystem probing code was in xfsprogs project (libdisk), and the other code is still in the parted (libparted).

And now about consolidation. The libblkid was merged into util-linux-ng (one year ago). The old version in e2fsprogs is still maintained for people who are very conservative. All new features go to libblkid in util-linux-ng project.

Some important functionality from libvolume_id was merged into libblkid including a new low-level API. The blkid(8) command supports new "-p" (low-level probe) and "-o udev" (udev output format) options now.

The libvolume_id was completely removed from udev project a few months ago. The mount(8) command uses only libblkid.

The libblkid has been heavily extended in the latest (incoming) util-linux-ng-2.17. It supports partition tables probing and allows to gather information about blkdev topology. This latest change allows to use libblkid instead of libdisk in mkfs programs (already in mke2fs and mkfs.xfs).

And finally libparted could be linked against libblkid. Currently, it uses libblkid for topology information only, but I hope one day it will use it for filesystems probing too.

The last remaining place where is any filesystem probing code is cfdisk. It will be fixed in some next util-linux-ng release.

So... now is excellent opportunity to say THANKS to Ted (e2fsprogs), Kay (udev), Christoph (xfsprogs) and to others who help me with this task.

[...yeah, this is my first blog post ... and yeah, my English is horrible:-)]