Identifying disks, drives and network mounts

[John Van Ostrand]

On Thu, 2006-09-07 at 01:07 -0400, Madison Kelly wrote:
> 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.

I don't think you'll be able to get partition creation times for either
x86 partitions or SAN partitions. Other types of block devices have that
information available, such as Logical Volumes (use
lvdisplay /dev/Volume00/LogVol01). I would suggest you look at file
system creation date. For ext2/3 use "tune2fs -l <devname>" I suspect
that most other modern file systems will have. You may be stuck when it
comes to FAT and network file systems though.

It's going to vary depending on the file system type. I think you're
best bet is to create an easily extensible method of identification.
Design in the ones that you can test now and let your users plug in the
ones that you don't have access to. Ideally it would be a libexec
command that is passed the file system or block device and it returns a
UUID. 

To make it easier for the user write the libexec commands to autodetect
as well and provide a program to cycle through the commands looking for
a successful detect. This should fit both novice users and pros alike.

Since some commands will be generic perhaps the libexec autodetect
commands could return a value indicating suitability. Generic commands
could return a different value so that the more specific commands are
used automatically. This could be layered so that there are more than
one signature file option. On Posix file systems a .filename could be
used. On FAT they could have hidden and system flags, etc. 

>    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?
-- 
John Van Ostrand
         Net Direct Inc.
 
Chief Technology Officer
564 Weber St. N. Unit 12
   Waterloo, ON N2L 5C6 
 map 
john-Da48MpWaEp0CzWx7n4ubxQ at public.gmane.org
        Ph: 519-883-1172
 ext.5102
Linux Solutions / IBM
Hardware
        Fx: 519-883-8533
 

--
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