[Possibly OT] Re: /proc/scsi/map

[Possibly OT] Re: /proc/scsi/map

[Austin Gonyou]

On Mon, 2002-06-17 at 21:40, Doug Ledford wrote:
> On Tue, Jun 18, 2002 at 01:06:48AM +0200, Kurt Garloff wrote:
> > Hi Doug,
> > 
> .... 
> > In case you just add controllers, you just need to make sure you get them the
> > same numbers again. A solution for this exists already:
> > * For a kernel where SCSI low-level drivers are loaded as modules,
> >   you just need to keep the order constant
> > * For compiled in SCSI drivers, use scsihosts=
> 
....
> No, this is not true.  If you add a new controller (for some new disks in 
> a new external enclosure or whatever), and that controller uses the same 
> driver as other controller(s) in your system, then you have no guarantee 
> of order.  For example, adding a 4th aic7xxx controller to your system 
> might or might not place the new controller at the end of the list 
> depending on PCI scan order, etc.  There simply is *no* guarantee here of 
> any consistent naming, so don't bother trying to claim there is.
> 

Taking a bit of an example from Veritas, would it be, at all, feasible
if n+ blocks were used at the end of the disk or partition(beginning
maybe?), to write a specific identifier that is unique to a specific
controller, or to make note of the drive serial number and store that on
the disk somewhere in some agreed upon understood way. 

Much like the private region on a veritas disk or volume. With the extra
accounting, which should only be needed during boot, or during
disk/volume manipulation, one could conceivably always have a sane
device map, all the time. 

As to the rest of the comments lower down on the original mail, I'd say
that this is *a lot* of trouble, versus the opposite, but if implemented
properly would be highly useful. Using LVM and the like, which does
something like this, seems to be fine for most people(even when moving
disks around, etc), but this ability, without the overhead of LVM in the
mix would seem a good idea for some. 

Just my $.02
TIA
-- 
Austin Gonyou <austin@digitalroadkill.net>

Re: [Possibly OT] Re: /proc/scsi/map

[Doug Ledford]

On Mon, Jun 17, 2002 at 10:24:40PM -0500, Austin Gonyou wrote:
> Taking a bit of an example from Veritas, would it be, at all, feasible
> if n+ blocks were used at the end of the disk or partition(beginning
> maybe?), to write a specific identifier that is unique to a specific
> controller, or to make note of the drive serial number and store that on
> the disk somewhere in some agreed upon understood way. 

Both LVM and the md code already do this.  Ext2 and ext3 also have volume 
labels that can be used for this purpose.  As much as I hate to admit it, 
this is the one area where I think MicroSoft did the right thing and 
snagged an unused byte in the partition table to mark the disks ordering 
(although we would need more than one byte).  By putting it in the 
partition table, it would only need to be dealt with by one area of code 
(the partition reading code), would work for all filesystems, would work 
for all LVM and md types of code, and would be universal on linux systems 
and provide consistent, persistent device naming.  Of course, if a disk 
dies and you put a new one in, then you have to rename the new disk to the 
old disks names when you partition it, but you would have to do that or 
something similar to that with all such possible solutions.

The simple fact of the matter is that to provide truly consistent, 
persistent device naming requires that the naming be "end-to-end".  You 
can not rely on *any* ordering issues (such as controllers, PCI busses, 
devices, etc), you have to read the name from the device itself and the 
name has to be totally irrespective of the devices current location on 
whatever bus it uses.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: [Possibly OT] Re: /proc/scsi/map

[Bryan Henderson]

>The simple fact of the matter is that to provide truly consistent,
>persistent device naming requires that the naming be "end-to-end".  You
>can not rely on *any* ordering issues (such as controllers, PCI busses,
>devices, etc), you have to read the name from the device itself and the
>name has to be totally irrespective of the devices current location on
>whatever bus it uses.

Plus, in a case like this, you don't want the name to change if you move
the data from one disk drive to another.  It's still the same volume, and
the volume is what you care about.

But we do have look out for other cases.  Like non-storage devices.

Re: [Possibly OT] Re: /proc/scsi/map

[Austin Gonyou]

On Tue, 2002-06-18 at 10:49, Bryan Henderson wrote:
....
> But we do have look out for other cases.  Like non-storage devices.
> 

I'm not sure what you mean here?


-- 
Austin Gonyou <austin@digitalroadkill.net>

Re: [Possibly OT] Re: /proc/scsi/map

[Doug Ledford]

On Tue, Jun 18, 2002 at 11:06:35AM -0500, Austin Gonyou wrote:
> 
> 
> On Tue, 2002-06-18 at 10:49, Bryan Henderson wrote:
> ....
> > But we do have look out for other cases.  Like non-storage devices.
> > 
> 
> I'm not sure what you mean here?

He's talking about the fact that you can put a volume label on a disk 
drive, but it's hard to do the same to a tape drive or maybe a SCSI 
DVD-RAM drive or anything else where you can't write to a permanent part 
of the device instead of a removeable part of the device.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: [Possibly OT] Re: /proc/scsi/map

[Austin Gonyou]

On Tue, 2002-06-18 at 11:08, Doug Ledford wrote:
> On Tue, Jun 18, 2002 at 11:06:35AM -0500, Austin Gonyou wrote:
> > 
> > 
> > On Tue, 2002-06-18 at 10:49, Bryan Henderson wrote:
> > ....
> > > But we do have look out for other cases.  Like non-storage devices.
> > > 
> > 
> > I'm not sure what you mean here?
> 
> He's talking about the fact that you can put a volume label on a disk 
> drive, but it's hard to do the same to a tape drive or maybe a SCSI 
> DVD-RAM drive or anything else where you can't write to a permanent part 
> of the device instead of a removeable part of the device.

Ahh...off-line storage devices. Kind of hard to write a label to a
non-storage device. (/dev/null is a non-storage device right? :) )


-- 
Austin Gonyou <austin@digitalroadkill.net>