Hey Karel, the libblkid revamp in a branch of util-linux-ng looks promising, and I really hope we find a way to have a single library pretty soon. Let's find out what will be needed for a possible replacement of libvolume_id with the util-linux-ng libblkid. We currently use volume_id in udev and HAL. Some distros also use it for mount and fsck. udev: ===== At the time util-linux-ng contains a released version of a revamped libblkid, which offers the needed features, I can port udev's vol_id to use libblkid, or we add the --export environment variable format to the blkid binary. We would need something like this, where the output of some characters is hex-encoded if needed. The mount integration of libblkid will need the encoding code anyway to lookup the udev created label/uuid links, so it might be good to just add it to the current binary: $ blkid --export /dev/sda5 BLKID_USAGE=filesystem BLKID_TYPE=ext3 BLKID_VERSION=1.0 BLKID_UUID_ENC=ea758d5a-d93d-4899-bec7-abf553a6f16c BLKID_LABEL_ENC=\x2f If that's not feasible, we can just keep the vol_id binary in udev, and link it against util-linux-ng's libblkid. Based on past experience with blkid, I require a formal statement, mentioned in the util-linux-ng blkid documentation, or just in the source code, that it will always allow raw byte-stream probing if asked for. :) I need to make sure, blkid will always offer a "non-smart" interface to its probing functions. Things like cache files, locks between concurrent invocations, parsing /proc files, readdir() in /dev, device-mapper queries, searching in the kernel modules directory, must be completely avoided for the udev use case. The probing must not apply any complex policies built into the library, it must just depend on the raw byte-stream that is passed to the binary/library. HAL: ==== At the same moment we switch udev to use libblkid, I will port HAL from libvolume_id to libbklid. It has similar requirements as udev, and we will make HAL just depend on a specific util-linux-ng version. After udev and HAL are converted, which would happen at the same time, I will remove libvolume_id from the udev tree, and the fsprobe configure option in util-linux-ng can be removed. We will only have a single library. mount: ====== If the current mount is compiled to use libblkid instead of libvolume_id, it does not use udev supplied information. To find a label or uuid of a volume, it opens in-process every device sequentially, which may take a long time, if some of the available block devices do not behave normally. Udev does this information gathering at device discovery, asynchronously with a thread per device, which does not have this problem. It can easily be simulated: $ modprobe scsi_debug max_luns=8 num_parts=2 $ echo 1 > /sys/module/scsi_debug/parameters/every_nth $ echo 4 > /sys/module/scsi_debug/parameters/opts $ ls -l /sys/class/block/ | wc -l 45 $ time blkid /dev/sda5: UUID="ea758d5a-d93d-4899-bec7-abf553a6f16c" ... ... real 102m29.909s user 0m0.000s sys 0m0.000s The current mount command, will show a similar behavior. Every simple mount by label/uuid, even for a device without any malfunction can run into such timeouts. A system may not even be able to boot up properly in such cases. If we replace libvolume_id, we (we as the current libvolume_id in mount users) need to be able to specify a different default behavior for mount, which will by default never try to open any other device. We just want to depend on udev maintained data. It can be a config file option somewhere, or a compile-time option, both should work fine. A commandline option to overwrite the configured default, and possibly scan all devices is still useful, but it must not be the default on systems we need to support. I'm looking forward to see all that happen. Karel, any estimation when we can start testing all this, and what we need to make all that happen? Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
