On Fri, 2009-01-09 at 01:41 +0000, Dean Loros wrote: > Yes--Thank you Colin---I look forward to test EXT4. As for the question > of vol_id vs blkid, I would really like to know why it was changed from > Debian in the first place......As Theo noted: "I assume there was *some* > reason that util-linux decided to break from Debian and use the vol_id > library instead of blkid, but I believe that was an incorrect decision." > libvolume_id and libblkid sometimes give different answers as to the content of the same block device. This can lead to different opinions as to which block device has a given UUID.
libblkid was used by the base tools such as mount and swapon which mount from /etc/fstab. But libvolume_id was used by the higher level tools such as udev and HAL which mount hotpluggable devices. That didn't cause too many problems. But then we switched to UUID-based mounting; our initramfs is udev based, so that means we use libvolume_id to mount the root filesystem by UUID. It also means we use libvolume_id to resume from hibernate, which is stored in the swap partition. Having mount and the initramfs disagree about which was your root partition, and having swapon and the initramfs disagree about which is your swap device... Bad Things Happened. So to solve the problem, we standardised on one library. Since SuSE had already written the patches, and util-linux was going through the util-linux -> util-linux-ng hiatus, libvolume_id was the one we picked. If the winds had been blowing from the opposite direction that day, we'd be having the same argument about breaking from Debian and patching hal, udev, initramfs, grub, etc. to use libblkid instead of libvolume_id. I can't please everyone ;-) The real problem is that we have two different libraries for doing the same thing. Actually, that's not entirely true. All libvolume_id contains are block device probing functions; you start off with a known block device (/dev/sdc1, for example) and ask it what it contains. libblkid is a bit more intelligent, it has a cache of known block devices and you can ask it for known UUIDs. If it doesn't know, it might scan new block devices; and if it does know, it double-checks to make sure it doesn't return you the wrong data. SuSE's patches (which we inherited) to util-linux get around the fact that libvolume_id doesn't behave this way by actually not using it at all. Instead they map UUID= and LABEL= mounts into /dev/disk/by-uuid and /dev/disk/by-label paths. These are maintained by udev based on its own probing calls with libvolume_id. Obviously because they're maintained by udev, there's a big drawback - it doesn't know if the filesystem changes. And that's why you have to reboot (or write the word "change" to the uevent file of the block device). That sucks. So the optimum future is to merge libblkid and libvolume_id; we only need one library. The final library should have a superset of both functionality. You should be able to ask it for information about an individual block device (and have as wide a range of support as libvolume_id does now), and you should be able to ask it for a UUID or LABEL using its cache. Ted, Kay and I have talked about this at various points since Plumbers' - I think we all agreed, but nobody's writing it quite yet <g> Scott -- Scott James Remnant sc...@canonical.com -- In order to support ext4, util-linux must use blkid (and not vol_id) https://bugs.launchpad.net/bugs/197311 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
