Re: Re: Search GPT partition in GRUB

[gburanov@gmail.com]

> The NTFS "UUID" (actually the volume serial number rather than a proper
> UUID) is 64 bits long, so we have a space of 2^64 possible UUIDs. That's
> very close to the number of stars in the observable universe.  I believe
> that the volume serial number is typically generated based on the date
> and some amount of randomness, although of course I can't verify that
> for certain from Microsoft's implementation (linux-ntfs simply generates
> a 64-bit random number).
> 
> Even with fairly conservative assumptions, though, the probability of an
> NTFS volume serial number collision is extremely small.  The probability
> of an NTFS volume serial number collision *on the same machine* - well,
> I rather expect that it's on the same general order as the probability
> of an asteroid dropping on your head.  I wouldn't worry about it if I
> were you!

Hello Colin
Thank you very much for the answer!  However, last night I was investigating NTFS volume serial number and GPT GUIDs.
  1) Volume serial number in NTFS is only 32 bits long (not 64), althought the reserved space is really 64 bit (this is done for the compatibility with FAT), where they got only 32 bits for volume serial number.
  2) The worse thing is that this number is not really designed to be unique (there is no single document where it's written to be unique). In the old times, MS used volume label to create serial number, which is not unique for sure. Now they use timestamp.
  3) Now, the worsiest sting is that 3rd part software sometimes does not change it (cause it's not documented that is must be unique). For example, you backup the volume and restore it to the free space on the same drive - and, gotcha, the serial is the same.


> > It would be ideal if we can search the GPT partition/disk by GUID -
> > that's what we got NTFS GUID for =)
> 
> That would be nice, and it might not be all that difficult to implement,
> but of course it would take up extra precious space in the core image.
> I don't think it's really necessary in this case.

The GPT GUID, on the other side, is DOCUMENTED to be unique. So, it's much better way to use it. I am not so familiar to grub, but I guess we can add GPT GUID support as additional module, so it will not take extra space for that.

I guess I need to write GPT GUID support for the GRUB (in sore image or as separate module), because we still need this in our own product.

There is one problem - I never wrote smth for grub before =) It seems you are familiar with grub - and know the place in the code where do I need to make changes. Maybe we can contact by mail, and I will write the implementation?

Regards,
Georgy

--
This message was sent on behalf of gburanov@gmail.com at openSubscriber.com
http://www.opensubscriber.com/message/grub-devel@gnu.org/13378639.html