Hi Mike,
On Wed, Oct 14, 2009 at 11:31:15PM +0200, Mike Hommey wrote:
> test: UUID="44f8ed49-19de-2dda-7b74-0021280083cf" VERSION="3" TYPE="VMFS_volume_member" USAGE="raid"
>
> $ /sbin/blkid -p -O 17825792 test
> test: UUID="44f8ed49-f328-fceb-cb65-0021280083cf" LABEL="toto" VERSION="31" TYPE="VMFS" USAGE="filesystem"
>
[...]
> Now, I am wondering about a few details. VMware ESX, as well as our tools,
> don't interpret the uuids the same way as blkid and libuuid does, compared
> to how it is stored on disk.
>
> This is what the 2 uuids above look like for ESX:
> 49edf844-da2dde19-747b-0021280083cf
> 49edf844-ebfc28f3-65cb-0021280083cf
Does this format match with any existing standard?
From my point of view introduce a new format is usually bad idea. We
already have tools for UUID parsing (for example libuuid) and it
seems that your format is incompatible.
Anyway, you can use arbitrary UUID in libblkid. The function
blkid_probe_sprintf_uuid() provides absolute freedom. For example
ntfs.c uses "%016" PRIX64 as UIID format.
> Additionally, on each physical volume, there is a reference to a logical volume
> uuid, stored at a couple sectors after the physical volume magic number,
> which I would like to expose through some variable. Do you think LOGICAL_UUID
For example for btrfs we use UUID for filesystem (logical volume?) and UUID_SUB
for device. It would be nice to use the same concept.
(Note that we also have EXT_JOURNAL that is for external ext[3,4] journal.)
> would be good ? Would blkid_probe_get_buffer be suited to get this information
> from the device ?
Yes, everything what you need is offset where is stored this information.
> Final question: what kind of information would you expect the commit message to
> contain ?
Well, the basic patch description + Signed-off-by: line. See
README.devel util-linux-ng.
> +struct vmfs_fs_info {
> + uint32_t magic;
> + uint32_t volume_version;
> + uint8_t version;
> + uint8_t uuid[16];
> + uint32_t mode;
> + char label[128];
Oh, this is huge label :-) Currently, we support 64 bytes only. But
that's minor problem, I'll enlarge the buffer.
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
