Hi, On Thu, Oct 15, 2009 at 03:10:07PM +0200, Karel Zak wrote: > > 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? Kind of. Actually, the main difference is byte ordering, and a missing dash. I can very much live with the missing dash. > 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. In such case, will UUID=theuuid on "mount" command line do the right thing? > > 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. That sounds fair. Mike -- 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
