On Fri, Nov 21, 2008 at 10:47:48AM +0100, Kay Sievers wrote:
> udev:
> =====
> 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.
I think sometimes people need to convert the (hex-encoded) names to
the real UUIDs/LABELs. It makes sense to support this feature in the
library to avoid multiple implementations.
My wish is to add "--lowprobe" and "--format={export,...}" to blkid
binary.
(Maybe we can also check argv[0] and enable this options automatically
when the name of the binary is "vol_id". So you can for backward
compatibility use a symlink /lib/udev/vol_id --> /bin/blkid. Depends
on your POV.)
> 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. :)
Ah man :-) It's completely separated API, so ...
> HAL:
> ====
>
> 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.
I'd like to provide at least one "overlapping release" -- it means
release when is possible to compile against old and new libraries.
Some people are very very conservative :-)
Ted's plan is to keep the old freezed libblkid in e2fsprogs.
> 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,
This is not true. The library has a cache, so if the device is
already cached it reads and verify the single device only. This
happen almost all time.
> 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.
... udev is gathering when the information is available, not all
mkfs/tunefs programs inform udev about UUID/LABEL changes. You
know...
IMHO the proper udev based mount(8) implementation should be:
- read disk-by symlink
- *verify* that the link match with LABEL/UUID on the device
- if the link *does not match*, call "the smart" libblkid API ;-)
I'd like to try to implement on inotify based blkidd, we will see how
this thing help us.
> 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.
It seems we need a config file for more things.
In long-term point of view we need to found *one* reliable way how to
work with UULDs/LABELs and use it in all distros. The scenario also
need fallback for non-udev based systems.
BTW, how do you resolve UUID/LABEL when you mount a root filesystem in
initrd?
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
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
