On Thu, Oct 15, 2009 at 03:24:51PM +0200, Mike Hommey wrote: > > > 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. Note that how UUID's are printed out by the uuid library (which is used by the blkid program) is defined by RFC 4122. It would be unfortunate if we try to magically byte swap things just for one file system. I grant that it's not fatal, since the VMFS's UUID is only going to be found in a VMFS-specific superblock location, and it's unlikely that we would be storing a VMFS UUID anywhere else. However, *do* please keep in mind that how a UUID gets printed isn't arbitrary, and is defined in an RFC standard specification --- and that form is/was also used by OSF DCE and Microsoft, as the same architect Paul Leach, was responsible for the UUID specification first used by Apollo RPC, and then OSF DCE, and later at Microsoft. So there is an industry-wide standard way of doing things, and I'm sorry if VMWare screwed things up. - Ted -- 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
