--------- Received message begins Here ---------
>
> > At some point people are going to realize that all the hacky magic that
> > has to happen before they can access devices sanely is far uglier than
> > /dev/dsk/c0t0d0s3, and this insanity will be trashbinned....
>
> Whats this c0t0d0s3. Thats woefully inadequate to describe a volume that
> is on a kernel managed multichanger on a fibrechannel fabric 8)
True, but it is sufficient to identify physical devices if it is thought of
as an address. The address of the changer+device is handled. The media is more
of a logical address, not physical. Logical addresses have to be handled
separately (as you noted below).
>
> Finding physical devices and finding volumes are two seperate problems. UUID's
> solve the volume problem. It solves 'find my home dir, find the root stick them
> here and here'. It doesnt solve 'format this tape'
Logical addressing requires a totally separate support. All of the systems
I have used do this via a mount/resource daemon + data base. The volume (whether
disk or tape) is first looked up to determine if it is available. If the
volume is a disk, the database is static (ie the logical volume id) and does
not require a UUID, though that can be used. The "format this tape" uses
the visual ID+logical ID (ie label), stored in a data base, to direct a device
mounter (a human or a robot, depending on implementation) to load the media.
Then the desired action can be taken (usually, but not always, including
relabling the media). Such action also requires that general users not have
direct access to the devices where the media resides, but must allocate them
for exclusive use. The media daemon can then mediate all interaction with the
physical device to prevent bypassing the labling of the media, and accessing
data that belongs to a different user.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:24 EST