This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFE: mount support for device UUID's


Hi Corinna,
On 09/10/2012, at 7:53 PM, Corinna Vinschen wrote:

> Hi Mark,
> 
> On Oct  4 10:47, Mark O'Keefe wrote:
>> Hi all,
>> 
>> I'm new to this list so not entirely sure of the protocol, but I'd like to suggest an enhancement
> 
> ...not a protocol as such, but it would be nice if you could restrict
> the number of chars per line to somewhat below 80 :-}

Sorry about that.  Unfortunately my mail program doesn't support this
so I had to eyeball where 80 characters was - obviously poorly :-)

> 
>> to the mount capabilities of cygwin.  I would guess I'm not the only one who plugs various
>> external drives into my PC and would like to predictably define where they get mounted
>> under cygwin.  At the moment this is limited to just the drive letter (which can change).  I
>> would like your thoughts on an enhancement which allowed the use of the drive UUID to
>> identify the connected drive letter, ie., make the drive letter dynamic.  The intent is to add
>> an optional parameter to fstab to support UUID.
> 
> In contrast to a mount table on a "real" UNIX, the Cygwin mount table is
> just the mapping from an arbitrary Windows path to an arbitrary POSIX
> path.  Devices don't count in this picture, not even really for the
> cygdrive mapping since DOS drive letters are NOT devices but paths in
> the first place.  From this point of view, using a UUID based approach
> to access drives is quite a change from the usual approach.
> 
> Having said that, I see how a new approach to access removable drives
> this way could be useful.

It would definitely be useful (IMHO).  I looked at it specifically for
supporting AMANDA backup with removable drives.  The idea being to
use a rotation of removable drives as the tapes.

> 
>> [...]
>> To cut to the chase, I've created a version which leverages aspects of the /proc virtual
>> filesystem, behaviours of Windows, blkid and the special file names of cygwin.
>> 
>> When a drive is first attached to Windows it creates a unique GUID for that drive.  This does
>> not change (unless you deliberately delete these from the registry).  These unique
>> references appear in the /proc filesystem as:  /proc/sys/GLOBAL??/Volume{GUID}
>> These are links to the device under /proc/sys/Device
>> 
>> Also under the /proc filesystem are the drive letter references:
>> /proc/sys/GLOBAL??/[A-Z]:
>> These link to the device under /proc/sys/Device also.
> 
> Right.
> 
>> So, you can map a unique device GUID to a drive letter dynamically using this information.
>> Now to get the UUID into the picture.
>> If you had a script which populated the UUID as a link to the unique volume you can map
>> the UUID to a drive letter dynamically by expanding the links at run-time.
>> 
>> /dev/disk/by-uuid/<UUID>    =>    /dev/sys/GLOBAL??/Volume{<GUID>}
>> /dev/sys/GLOBAL??/Volume{<GUID>}    =>    /dev/sys/Device/<device>
>> /dev/sys/Device/harddisk[0-9]*/partition[0-9]*    =>    /dev/sys/Device/<device>
> 
> Uh, hang on.  You meant /proc/sys/..., right?  You are not suggesting
> another redirection via a not yet existing /dev/sys/... I hope?

Yes, I did mean /proc/sys.  Typo.  Sorry for the confusion.

> 
>> http://www.cygwin.com/cygwin-ug-net/using-specialnames.html
>> Provides the mapping of POSIX device name to Internal NT device name  (3rd line above).
>> So, using this you can take the output of blkid and get a valid mapping to the various
>> components required above.
>> 
>> You can use a bootstrap process to create the /dev/disk/by-uuid/<UUID> link for each
>> of your devices the first time you attach them (manual process) and after this rely on
>> the /proc filesystem to reliably map a connected UUID drive to the mapped drive letter.
>> You can also rely on this to determine if it is connected as the /proc filesystem only shows
>> the links for connected devices, so while the /dev/disk/by-uuid link is permanent, the
>> destination only exists if the drive is mounted.
> 
> ...which is kind of weird, considering that Linux /dev/disk/... only
> contains drive information for connected drives as well...

Agreed.  It would certainly be nice to have this populated based on
what is connected, however that introduces the dependency on
libblkid.  I'm not sure this is acceptable inside the core of
cygwin.  Alternative would be to extract (copy) the related code
over to cygwin (not sure how viable that is and it introduces
maintenance implications).  It would also be necessary to look
at how to get the best performance out of this (caching and
recognising when drives connect/disconnect).  I didn't know enough
about the internals of cygwin to determine how feasible this was.
If the connect/disconnect of a drive could trigger the necessary
drive read to get the UUID and populate this as a virtual directory
then that would be a better solution that is resilient to change.

> 
>> Sample directory listings:
>> 
>> $ ls -l /dev/disk/by-uuid
>> total 6.0K
>> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 14:56 022A4E072A4DF865 -> /proc/sys/GLOBAL??/Volume{07f378c0-0785-11e2-8b16-9d8354493d98}
>> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 11:12 20E819DCE819B150 ->/proc/sys/GLOBAL??/Volume{33795e42-562b-11e1-9e43-806e6f6e6963}
>> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 15:07 5E83-34DB ->/proc/sys/GLOBAL??/Volume{a056ffe4-c49b-11e1-9a60-e01fff2983d8}
>> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 14:56 78F07EF2F07EB5CA -> /proc/sys/GLOBAL??/Volume{82620ba9-ebef-11e1-b0aa-c0aa65e5609c}
>> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  2 17:41 BC28CC9C28CC56D4 ->/proc/sys/GLOBAL??/Volume{ff6beeb7-ef41-11e1-be0b-bb34ac766d9f}
>> lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  2 17:42 D258228358226707 ->/proc/sys/GLOBAL??/Volume{ff6beea8-ef41-11e1-be0b-bb34ac766d9f}
> 
> Ok.  But Linux UUIDs for fixed disks are equivalent in layout to Windows
> UUIDs/GUIDs.  So why not just use the GUID "as is"?

The Windows UUIDs/GUIDs can change (though that isn't common and I
believe does require a specific user action to cause it).  Also, 
they aren't consistent with the result of running blkid.  If using
UUID in mount you would expect it to match the blkid output.

> 
>  lrwxrwxrwx 1 Administrators SYSTEM 63 Oct  3 14:56 07f378c0-0785-11e2-8b16-9d8354493d98 -> /proc/sys/GLOBAL??/Volume{07f378c0-0785-11e2-8b16-9d8354493d98}
> 
> But here's an important question.  What exactly have you won by
> adding the redirection via /dev/disk/by-uuid?  The directory does
> not contain any new information which isn't already available via
> /proc/sys/GLOBAL??.

Actually it does.  As stated above, the UUID/GUID of Windows does
not match the UUID extracted from blkid.  If you run blkid on the
disk you get the correct value.  This value is the same as the
value returned if you then connect that disk to a linux based
system.  This value doesn't change without physical change to
that disk partitioning, unlike the UUID/GUID of Windows.

> 
>> Sample fstab:
>> # For a description of the file format, see the Users Guide
>> # http://cygwin.com/cygwin-ug-net/using.html#mount-table
>> 
>> # This is default anyway:
>> # none /cygdrive cygdrive binary,posix=0,user 0 0
>> 
>> /slots UUID=D258228358226707 /mnt/vtapes/slots none binary,user
>> /slots UUID=BC28CC9C28CC56D4 /mnt/archive/slots none binary,user
>> 
>> /slots UUID=5E83-34DB /mnt/4Gmodem/slots none binary,user
> 
> I wouldn't like to allow a change in the fstab layout which introduces
> variable positions for adjacent entries.  Either just
> 
>  UUID=07f378c0-0785-11e2-8b16-9d8354493d98
> 
> and ignore the ability to mount subdirs of drives, or something like
>  UUID=07f378c0-0785-11e2-8b16-9d8354493d98/slots
> 
I like this option over the previous.  What I noticed was that if
you did the first, then it overrides the cygdrive mount point.
I think the second option allows for the first as a variant anyway.
It is more flexible.

> This addition to fstab would already be possible if the UUID is
> the same as used by Windows and the mount mechanism could do this without
> having to bootstrap a /dev/disk dir.
> 
> Btw., did you know that the drive is already accessible from within
> Cygwin?  Try
> 
>  $ cd '/proc/sys/GLOBAL??/Volume{07f378c0-0785-11e2-8b16-9d8354493d98}/'
> 
Yes, I did know this.  I've been trawling around in there following
how things related to determine how to establish the relationships I
wanted :-)

> (note the trailing slash which is required to access the root dir of
> the drive)
> 
> This already allows an equivalent mechanism today, just using symlinks
> rather than mount table entries:
> 
>  $ ln -s '/proc/sys/GLOBAL??/Volume{07f378c0-0785-11e2-8b16-9d8354493d98}/slots' /mnt/vtapes/slots
>  $ cd /mnt/vtapes/slots
> 
In my case this doesn't achieve what I want as I want to be able
to switch out drives and have them map to the same location.
This would create an issue if I mounted 2 drives that want the same
location of course, but that is a user error.

Backup to drive-1.  When full, swap out and put in drive-2.  Backup
continues without need to change configuration.  The drive bay
is acting like a tape slot.  An operator getting the email to swap
drives need know nothing about the configuration, just which
drive to insert.


> 
> Corinna
> 
> -- 
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader          cygwin AT cygwin DOT com
> Red Hat

Cheers,
Mark.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]