Identifying disks, drives and network mounts

Madison Kelly linux-5ZoueyuiTZhBDgjK7y7TUQ at public.gmane.org
Thu Sep 7 05:07:02 UTC 2006


John Van Ostrand wrote:
> On Wed, 2006-09-06 at 12:49 -0400, Madison Kelly wrote:
>> Hi all,
>>
>>    I have been struggling with this problem for a couple of years now 
>> (yes, really!) and have tried a couple different solutions that were 
>> never as robust as I would like. So I am hoping some brainiac here might 
>> have an idea! :)
> ...
>>    Any ideas (or corrections to my assumptions) would be greatly 
>> appreciated! I realize I may need to settle on a combination of 
>> solutions, but I'd like to keep that to a minimum, too.
> 
> This is a problem that has really only surfaced relatively recently 
> (last 10 years). Most new file systems and volume managers should 
> support some form of unique ID.
> 
> I think you are not going to find a single solution. You've already 
> identified the ext2/3 UUID from blkid.
> 
> If you are dealing with LVM volumes you could use the UUIDs there. 
> (vgdisplay or lvdisplay.)
> 
> You may just have to find UUIDs in other file systems. Failing that the 
> hidden file is a good idea, although like you said, not reliable. 
> Finally you could use fs data like file system type, sizes, creation 
> date, etc to come up with a pseudo unique ID.

Thanks for the idea!

   I am afraid I can not figure out how to read/find the partition 
creation time... That would be a great help if you could give me a 
pointer on this.

   Unless I get a better idea, I think what I will settle on is a 
three-step ID system. The first, and ideal method will be to create/read 
a 'signature' file that will have a UUID (generated by the perl 
'Data::UUID' module).

   I will also record two other IDs; The second being the UUID returned 
by 'blkid' when available. Lastly will be an MD5 hash (or something 
similar) based on as static values as I can dig up (hence why the 
partition's creation date would be so helpful). An example when this 
third, least ideal step would be useful would be on NFS/SMB mounted 
partitions. They aren't examined by 'blkid' so no UUID would be 
available. Instead I could/would create a hash based on the hostname and 
share. Obviously this is easily broken, and would only be used as a 
"last-ditch" effort to ID the partition.

   I think I will try to find/record all three bits so that, for 
example, if the signature file was accidentally deleted I could try to 
match one of the less-ideal methods and try to restore the signature 
file (with the user confirming the guess).

   It's a little cumbersome, but lacking a more portable/universal 
method I can't think of a better way at the moment.

   Comments (positive or negative!) on this scheme? Any obvious problems 
or points of failure?

   Thanks again!!

Madison
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wini/Mailing_lists





More information about the Legacy mailing list