login
Search
An interesting thread on the lkml began with a patch to try and move an IOCTL call used to obtain the SCSI ID of a SCSI device from the block layer into the SCSI subsystem. Linux creator Linus Torvalds was quite vehement in his responses, explaining that there is no such thing as a SCSI ID, "stop it now. We should kill that ioctl, not try to make it look like it is sensible. It's not a sensible way to look up SCSI devices, and the fact that some SCSI people think it is is doesn't make it so." The heated debate has come up many times on the kernel mailing list, with arguments on both sides of the issue. In the most recent thread, Linus went on to explain:
"It was a stupid idea even in the 80's. It's only gotten stupider since. Now, during the 80's it was at least _excusable_. It was reasonable to think that you can just enumerate the controllers. And it was simple, and since hotplug controllers back then was "operator plug", not the modern kind of "they magically show up", it worked and controller numbers _meant_ something (even though they'd change when you switched things around, but you can expect that).
"These days, you just cannot enumerate controllers in any meaningful manner. I don't think you ever really could, but at least with static hardware, any random enumeration was as good as any other."
From: Bodo Eggert [email blocked]
To: linux-kernel
Subject: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Sun, 26 Mar 2006 21:28:28 +0200 (CEST)
Having a SCSI ID is a generic SCSI property, therefore reading it should
not be restricted to sg. The SCSI_IOCTL_GET_IDLUN from scsi is limited
below the kernel data types, so it isn't an adequate replacement.
This patch moves SG_GET_SCSI_ID from sg to scsi while renaming it to
SCSI_IOCTL_GET_PCI. Additionally, I renamed struct sg_scsi_id to struct
scsi_ioctl_id, since it is no longer restricted to sg. The corresponding
typedef will be gone.
Signed-off-by: Bodo Eggert [email blocked]
---
This patch applies to 2.6.16. No structural change is made to the struct
nor the IOCTL number, so userspace will continue to work properly.
Maybe this IOCTL should be extended to return the 64 bit LUN, but I wasn't
able to find out enough details to do the change within reasonable time.
diff -pruN -X dontdiff 2.6.15.ori/drivers/scsi/scsi_ioctl.c 2.6.15/drivers/scsi/scsi_ioctl.c
--- 2.6.15.ori/drivers/scsi/scsi_ioctl.c 2006-02-08 15:10:48.000000000 +0100
+++ 2.6.15/drivers/scsi/scsi_ioctl.c 2006-03-26 20:24:24.000000000 +0200
@@ -434,6 +434,27 @@ int scsi_ioctl(struct scsi_device *sdev,
START_STOP_TIMEOUT, NORMAL_RETRIES);
case SCSI_IOCTL_GET_PCI:
return scsi_ioctl_get_pci(sdev, arg);
+ case SG_GET_SCSI_ID:
+ if (!access_ok(VERIFY_WRITE, arg, sizeof (struct scsi_ioctl_id)))
+ return -EFAULT;
+ else {
+ struct scsi_ioctl_id __user *idp = arg;
+
+ __put_user((int) sdev->host->host_no,
+ &idp->host_no);
+ __put_user((int) sdev->channel,
+ &idp->channel);
+ __put_user((int) sdev->id, &idp->scsi_id);
+ __put_user((int) sdev->lun, &idp->lun);
+ __put_user((int) sdev->type, &idp->scsi_type);
+ __put_user((short) sdev->host->cmd_per_lun,
+ &idp->h_cmd_per_lun);
+ __put_user((short) sdev->queue_depth,
+ &idp->d_queue_depth);
+ __put_user(0, &idp->unused[0]);
+ __put_user(0, &idp->unused[1]);
+ return 0;
+ }
default:
if (sdev->host->hostt->ioctl)
return sdev->host->hostt->ioctl(sdev, cmd, arg);
diff -pruN -X dontdiff 2.6.15.ori/drivers/scsi/sg.c 2.6.15/drivers/scsi/sg.c
--- 2.6.15.ori/drivers/scsi/sg.c 2006-02-08 15:10:48.000000000 +0100
+++ 2.6.15/drivers/scsi/sg.c 2006-03-11 11:20:16.000000000 +0100
@@ -871,29 +871,6 @@ sg_ioctl(struct inode *inode, struct fil
return 0;
case SG_GET_LOW_DMA:
return put_user((int) sfp->low_dma, ip);
- case SG_GET_SCSI_ID:
- if (!access_ok(VERIFY_WRITE, p, sizeof (sg_scsi_id_t)))
- return -EFAULT;
- else {
- sg_scsi_id_t __user *sg_idp = p;
-
- if (sdp->detached)
- return -ENODEV;
- __put_user((int) sdp->device->host->host_no,
- &sg_idp->host_no);
- __put_user((int) sdp->device->channel,
- &sg_idp->channel);
- __put_user((int) sdp->device->id, &sg_idp->scsi_id);
- __put_user((int) sdp->device->lun, &sg_idp->lun);
- __put_user((int) sdp->device->type, &sg_idp->scsi_type);
- __put_user((short) sdp->device->host->cmd_per_lun,
- &sg_idp->h_cmd_per_lun);
- __put_user((short) sdp->device->queue_depth,
- &sg_idp->d_queue_depth);
- __put_user(0, &sg_idp->unused[0]);
- __put_user(0, &sg_idp->unused[1]);
- return 0;
- }
case SG_SET_FORCE_PACK_ID:
result = get_user(val, ip);
if (result)
@@ -1071,6 +1048,7 @@ sg_ioctl(struct inode *inode, struct fil
case SCSI_IOCTL_GET_IDLUN:
case SCSI_IOCTL_GET_BUS_NUMBER:
case SCSI_IOCTL_PROBE_HOST:
+ case SCSI_IOCTL_GET_ID:
case SG_GET_TRANSFORM:
if (sdp->detached)
return -ENODEV;
diff -pruN -X dontdiff 2.6.15.ori/include/scsi/scsi.h 2.6.15/include/scsi/scsi.h
--- 2.6.15.ori/include/scsi/scsi.h 2006-02-08 15:11:08.000000000 +0100
+++ 2.6.15/include/scsi/scsi.h 2006-03-26 20:36:54.000000000 +0200
@@ -245,6 +245,17 @@ struct scsi_lun {
__u8 scsi_lun[8];
};
+struct scsi_ioctl_id { /* used by SCSI_IOCTL_GET_ID ioctl() */
+ int host_no; /* as in "scsi<n>" where 'n' is one of 0, 1, 2 etc */
+ int channel;
+ int scsi_id; /* scsi id of target device */
+ int lun;
+ int scsi_type; /* TYPE_... defined in scsi/scsi.h */
+ short h_cmd_per_lun;/* host (adapter) maximum commands per lun */
+ short d_queue_depth;/* device (or adapter) maximum queue length */
+ int unused[2]; /* unused part should be zero */
+}; /* 32 bytes long on i386 */
+
/*
* MESSAGE CODES
*/
@@ -427,4 +438,11 @@ struct scsi_lun {
/* Used to obtain the PCI location of a device */
#define SCSI_IOCTL_GET_PCI 0x5387
+/* The following ioctl has a 'struct scsi_ioctl_id *' object as its 3rd argument. */
+/* 'struct scsi_ioctl_id' was renamed from 'sg_scsi_id_t'. */
+#define SCSI_IOCTL_GET_ID 0x2276 /* Yields fd's bus, chan, dev, lun + type */
+#define SG_GET_SCSI_ID SCSI_IOCTL_GET_ID /* old name */
+/* SCSI id information can also be obtained from SCSI_IOCTL_GET_IDLUN, *
+ * but that is limited in range (/usurally/ no problem ...) */
+
#endif /* _SCSI_SCSI_H */
diff -pruN -X dontdiff 2.6.15.ori/include/scsi/sg.h 2.6.15/include/scsi/sg.h
--- 2.6.15.ori/include/scsi/sg.h 2005-06-17 21:48:29.000000000 +0200
+++ 2.6.15/include/scsi/sg.h 2006-03-11 12:10:14.000000000 +0100
@@ -155,18 +155,6 @@ typedef struct sg_io_hdr
#define SG_INFO_DIRECT_IO 0x2 /* direct IO requested and performed */
#define SG_INFO_MIXED_IO 0x4 /* part direct, part indirect IO */
-
-typedef struct sg_scsi_id { /* used by SG_GET_SCSI_ID ioctl() */
- int host_no; /* as in "scsi<n>" where 'n' is one of 0, 1, 2 etc */
- int channel;
- int scsi_id; /* scsi id of target device */
- int lun;
- int scsi_type; /* TYPE_... defined in scsi/scsi.h */
- short h_cmd_per_lun;/* host (adapter) maximum commands per lun */
- short d_queue_depth;/* device (or adapter) maximum queue length */
- int unused[2]; /* probably find a good use, set 0 for now */
-} sg_scsi_id_t; /* 32 bytes long on i386 */
-
typedef struct sg_req_info { /* used by SG_GET_REQUEST_TABLE ioctl() */
char req_state; /* 0 -> not used, 1 -> written, 2 -> ready to read */
char orphan; /* 0 -> normal request, 1 -> from interruped SG_IO */
@@ -195,10 +183,6 @@ typedef struct sg_req_info { /* used by
#define SG_SET_RESERVED_SIZE 0x2275 /* request a new reserved buffer size */
#define SG_GET_RESERVED_SIZE 0x2272 /* actual size of reserved buffer */
-/* The following ioctl has a 'sg_scsi_id_t *' object as its 3rd argument. */
-#define SG_GET_SCSI_ID 0x2276 /* Yields fd's bus, chan, dev, lun + type */
-/* SCSI id information can also be obtained from SCSI_IOCTL_GET_IDLUN */
-
/* Override host setting and always DMA using low memory ( <16MB on i386) */
#define SG_SET_FORCE_LOW_DMA 0x2279 /* 0-> use adapter setting, 1-> force */
#define SG_GET_LOW_DMA 0x227a /* 0-> use all ram for dma; 1-> low dma ram */
--
as appealing as it might seem, it is impossible to patch or upgrade users
-- Security Warrior
From: Linus Torvalds [email blocked]
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Sun, 26 Mar 2006 14:30:12 -0800 (PST)
On Sun, 26 Mar 2006, Bodo Eggert wrote:
>
> Having a SCSI ID is a generic SCSI property
No it's not.
Havign a SCSI ID is a f*cking idiotic thing to do.
Only idiots like Joerg Schilling thinks that any such thing even _exists_.
It does not, never has, and never will.
The way you reach a SCSI device is through the device filename, and trying
to use controller/channel/id/lun naming IS INSANE!
Stop it now. We should kill that ioctl, not try to make it look like it is
sensible. It's not a sensible way to look up SCSI devices, and the fact
that some SCSI people think it is is doesn't make it so.
The fact is, you CANNOT ID a SCSI device that way. Look at how /sys does
it, and realize that there's a damn good reason we do it that way. We ID
the same device in many different ways, because different people want to
ID it differently.
You can ask "what's the first device we enumerated", you can ask "what's
the physical path to the device" or you can ask "what's the intrisic UUID
of the device". But the controller/channel/id/lun thing is just stupid.
You can look it up that way if you want to, but I refuse to have idiotic
interfaces that somehow try to make that the "official" name, when it
clearly is NOT.
Linus
From: Jan Engelhardt [email blocked]
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 27 Mar 2006 01:19:11 +0200 (MEST)
>> Having a SCSI ID is a generic SCSI property
>
>No it's not.
>Havign a SCSI ID is a f*cking idiotic thing to do.
>
>Only [...] think that any such thing even _exists_.
>It [...] never has, and never will.
Ah. So all the minix, bsd and sun c?t?[dps]? naming is based on what then
(someone drinking just too much coffe?), if BTL/CTD/HCIL (call it what you
want) never existed?
Jan Engelhardt
From: Linus Torvalds [email blocked]
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Sun, 26 Mar 2006 16:06:56 -0800 (PST)
On Mon, 27 Mar 2006, Jan Engelhardt wrote:
>
> Ah. So all the minix, bsd and sun c?t?[dps]? naming is based on what then
> (someone drinking just too much coffe?), if BTL/CTD/HCIL (call it what you
> want) never existed?
Right.
It was a stupid idea even in the 80's. It's only gotten stupider since.
Now, during the 80's it was at least _excusable_. It was reasonable to
think that you can just enumerate the controllers. And it was simple, and
since hotplug controllers back then was "operator plug", not the modern
kind of "they magically show up", it worked and controller numbers _meant_
something (even though they'd change when you switched things around, but
you can expect that).
These days, you just cannot enumerate controllers in any meaningful
manner. I don't think you ever really could, but at least with static
hardware, any random enumeration was as good as any other.
Linus
From: Douglas Gilbert [email blocked]
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 27 Mar 2006 10:03:37 -0500
Linus Torvalds wrote:
>
> On Sun, 26 Mar 2006, Bodo Eggert wrote:
>
>>Having a SCSI ID is a generic SCSI property
>
>
> No it's not.
>
> Havign a SCSI ID is a f*cking idiotic thing to do.
>
> Only idiots like Joerg Schilling thinks that any such thing even _exists_.
> It does not, never has, and never will.
>
> The way you reach a SCSI device is through the device filename, and trying
> to use controller/channel/id/lun naming IS INSANE!
>
> Stop it now. We should kill that ioctl, not try to make it look like it is
> sensible. It's not a sensible way to look up SCSI devices, and the fact
> that some SCSI people think it is is doesn't make it so.
>
> The fact is, you CANNOT ID a SCSI device that way. Look at how /sys does
> it, and realize that there's a damn good reason we do it that way. We ID
> the same device in many different ways, because different people want to
> ID it differently.
>
> You can ask "what's the first device we enumerated", you can ask "what's
> the physical path to the device" or you can ask "what's the intrisic UUID
> of the device". But the controller/channel/id/lun thing is just stupid.
> You can look it up that way if you want to, but I refuse to have idiotic
> interfaces that somehow try to make that the "official" name, when it
> clearly is NOT.
Linus,
There are two things that really count:
1) the identifier (preferably a world wide unique name)
of the logical unit that is being addressed
2) a topological description of how that logical unit
is connected
For the last 25 years various OS SCSI subsystems have used
variants of 2) as a proxy for 1). Modern SCSI disks (and
soon SATA disks) have a world wide unique name associated
with their logical unit.
So why are modern SCSI standards full of terms like
I_T_L ** and I_T_L_Q nexus? Probably because the topology,
especially when there are multiple paths to the same
logical unit, is significant.
Linux's <hctl> may be a ham fisted way of describing
a path through a topology, but it easily beats /dev/sdabc
and /dev/sg4711 .
With a device node name like /dev/sdabc, a SCSI INQUIRY or
an ATA IDENTIFY DEVICE command can be sent to ascertain 1)
but I am unaware of any command sent to a logical unit that
will yield 2).
** that is: the nexus of an Initiator port, a Target port
and a Logical unit number.
Doug Gilbert
From: Linus Torvalds [email blocked]
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 27 Mar 2006 09:15:35 -0800 (PST)
On Mon, 27 Mar 2006, Douglas Gilbert wrote:
>
> There are two things that really count:
> 1) the identifier (preferably a world wide unique name)
> of the logical unit that is being addressed
> 2) a topological description of how that logical unit
> is connected
And "SCSI ID" doesn't describe either.
> Linux's <hctl> may be a ham fisted way of describing
> a path through a topology, but it easily beats /dev/sdabc
> and /dev/sg4711 .
Sure, you can easily beat it by selecting what you compare it against.
But face it, /dev/sdabc or /dev/sg4711 simply isn't what you should
compare against. What you should compare against is
/dev/cdrom
/sys/bus/ide/devices/0.0/block:hda/dev
/dev/uuid/3d9e6e8dfaa3d116
..
and a million OTHER ways to specify which device you're interested in.
The fact is, they can potentially all do the SCSI command set. And a "SCSI
ID" makes absolutely zero sense for them (those three devices may be the
same device, they may not be, they might be on another machine, who
knows..)
> With a device node name like /dev/sdabc, a SCSI INQUIRY or
> an ATA IDENTIFY DEVICE command can be sent to ascertain 1)
> but I am unaware of any command sent to a logical unit that
> will yield 2).
AND NEITHER WILL SCSI_ID. So what the h*ll is your point?
If you want to know how the damn thing is physically connected, you want
to use a path like
/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host0/target0:0:0/0:0:0:0/block:sda/dev
Note how, for example, this says 0:0:0:0, which happens to be the
controller/channel/id/lun information for that "SCSI device". Notice how
it is all zeroes? It's because that whole concept doesn't make any sense
for things like USB storage, which has a totally different way to address
the things.
But that thing really _does_ describe the physical location of that block
device (actually, that particular file just contains the information about
what the device node is for the device, but never mind).
And if you want to _use_ the device, you'd probably use a name like
/dev/disk/by-path/usb-0F406C5032802890:0:0:0 (which is that same device,
actually), or, more commonly /dev/disk/by-uuid/1468B594FC37ECF8, which
happens to be the second partition on that physical device and which
stays the same even when you plug that same disk in with firewire.
(Or, in this case, you migt actually want to use /dev/disk/by-label/rEFIt,
which is that same partition on that USB device, but in a human-readable
labeled form).
Again, the "SCSI ID" is a total and utter crock. IT HAS ABSOLUTELY NO
VALID USE. It does _not_ describe what you claim it describes, and it is
_not_ in any way superior to all the other ways of getting to that device.
Linus
From: Matthew Wilcox [email blocked]
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 27 Mar 2006 10:25:30 -0700
On Mon, Mar 27, 2006 at 09:15:35AM -0800, Linus Torvalds wrote:
> On Mon, 27 Mar 2006, Douglas Gilbert wrote:
> >
> > There are two things that really count:
> > 1) the identifier (preferably a world wide unique name)
> > of the logical unit that is being addressed
> > 2) a topological description of how that logical unit
> > is connected
>
> And "SCSI ID" doesn't describe either.
>
> > Linux's <hctl> may be a ham fisted way of describing
> > a path through a topology, but it easily beats /dev/sdabc
> > and /dev/sg4711 .
>
> Sure, you can easily beat it by selecting what you compare it against.
>
> But face it, /dev/sdabc or /dev/sg4711 simply isn't what you should
> compare against. What you should compare against is
>
> /dev/cdrom
> /sys/bus/ide/devices/0.0/block:hda/dev
> /dev/uuid/3d9e6e8dfaa3d116
> ..
>
> and a million OTHER ways to specify which device you're interested in.
>
> The fact is, they can potentially all do the SCSI command set. And a "SCSI
> ID" makes absolutely zero sense for them (those three devices may be the
> same device, they may not be, they might be on another machine, who
> knows..)
If this ioctl is generally supported, then you'll be able to find out if
they're all the same ;-)
From: Linus Torvalds [email blocked]
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 27 Mar 2006 09:43:30 -0800 (PST)
On Mon, 27 Mar 2006, Matthew Wilcox wrote:
> > compare against. What you should compare against is
> >
> > /dev/cdrom
> > /sys/bus/ide/devices/0.0/block:hda/dev
> > /dev/uuid/3d9e6e8dfaa3d116
> > ..
> >
> > and a million OTHER ways to specify which device you're interested in.
> >
> > The fact is, they can potentially all do the SCSI command set. And a "SCSI
> > ID" makes absolutely zero sense for them (those three devices may be the
> > same device, they may not be, they might be on another machine, who
> > knows..)
>
> If this ioctl is generally supported, then you'll be able to find out if
> they're all the same ;-)
Sorry, but no. You didn't read the other example in my email.
Many (most) Linux devices will actually have 0:0:0:0 in that field.
Because the SCSI ID simply doesn't make sense to them, and they have none.
So it's _not_ a unique ID.
For example, look at linux/block/scsi_ioctl.c, and realize that because I
wanted to make sure that you could run "cdrecord dev=/dev/hdc", it does a
few ioctl's that cdrecord wanted. In particular, it does
SCSI_IOCTL_GET_IDLUN and SCSI_IOCTL_GET_BUS_NUMBER. Take a look at what it
actually returns, and how it explicitly does NOT try to claim that those
numbers "mean" anything.
The fact is, BUS/ID/LUN crap really doesn't make sense for the majority of
devices out there. Never has, never will. The fact that old-fashioned SCSI
devices think of themselves that way has absolutely zero to do with
reality today.
If you want to know whether two devices are the same or not, you should do
a "stat()" on the device node, and look at "st->rdev". No, it's not in any
way guaranteed either, but it's actually a hell of a better rule than
looking at ID/LUN information.
Trying to make more people use UUID's is the way to _really_ distinguish
devices from each other.
Linus
From: Alan Cox [email blocked]
Subject: Re: [PATCH] Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 27 Mar 2006 20:54:47 +0100
On Llu, 2006-03-27 at 09:43 -0800, Linus Torvalds wrote:
> The fact is, BUS/ID/LUN crap really doesn't make sense for the majority of
> devices out there. Never has, never will. The fact that old-fashioned SCSI
> devices think of themselves that way has absolutely zero to do with
> reality today.
It is still a very visible reality if you work in a data centre or with
server kit, or if you have tape arrays or multi-CD towers. The LUN or
device number in particular are generally the number emblazoned on each
slot in the unit and knowing the LUN reliably is sort of critical to not
making embarrasing (and career limiting) screwups when swapping drives.
Controller is a pretty abstract concept and except on arrays so is
device, but both device and LUN do need to be accessible reliably for
the hardware that thinks that way. What other hardware does is
irrelevant and "-EINVAL" seems as good an answer as anything.
Alan
From: Douglas Gilbert [email blocked]
Subject: Re: RFC: Move SG_GET_SCSI_ID from sg to scsi
Date: Mon, 06 Mar 2006 14:32:48 -0500
Bodo Eggert wrote:
> I suggest moving the SG_GET_SCSI_ID ioctl from sg to scsi, since it's
> generally usefull and the alternative function SCSI_IOCTL_GET_IDLUN
> is limited in range (in-kernel data types may be larger) and
> functionality (type, ...).
Bodo,
ioctls, especially new ones, have become very unpopular
in the linux kernel. Whoever implemented the SG_IO ioctl
in the block layer moved just enough other sg ioctls to
fool cdrecord that it was talking to the sg driver. The
SG_GET_SCSI_ID ioctl didn't make the cut, probably because
cdrecord didn't use it.
Mind you, I think it is correct to (try and) move
SG_GET_SCSI_ID to the SCSI subsystem rather than
the block layer. Otherwise we would not be able
to use your proposed ioctl on non-block, sg visible
only devices (e.g. a SCSI enclosure (SES protocol)).
> However, I have some questions about that ioctl:
>
> - There is the concept of 8-Byte-LUNs: Are they mapped to integer LUNs?
> Should the extra space in the struct sg_scsi_id be used for that?
> Or should I abandon the idea and create a new IOCTL instead?
Yes, the SG_GET_SCSI_ID ioctl should allow for 8 byte
LUNs and that is a flaw in the current design. It is
no excuse that the rest of the SCSI subsystem has a
similar shortcoming.
In linux there is also a move away from the host_number,
channel_number, target_identifier and LUN tuple used
traditionally by many Unix SCSI subsystems (most do not
have the second component: channel_number). At least the
LUN is not controversial (as long as it is 8 byte!). The
target_identifier is actually transport dependent (but
could just be a simple enumeration). The host_number is
typically an enumeration over PCI addresses but some
other type of computer buses (e.g. microchannel) could be
involved.
> - The original IOCTL will check for sdp->detached. If the moved-to-scsi
> ioctl is called, the check will be done before chaining from sg, but what
> will I need to check if it's called on a non-sg device?
That should not be needed as the open file descriptor
to the SCSI device should be sufficient to keep the
relevant objects alive even if the device was just hot
unplugged.
> - Are there any (planned) changes that will conflict with this patch?
There is this thing called sysfs which is advertised
as an ioctl replacement. However if a routine is given
an open device node and you want to find its identity
an ioctl does have some advantages over a procfs followed
by a sysfs trawl. Just like ioctl related structures,
sysfs also changes, frustrating applications built on
it. Sysfs might even change more often than a well designed
ioctl since sysfs is often tightly bound to the driver
software architecture which may change without impacting
interfaces.
Lets see if this post gets a response.
Doug Gilbert
Alan wins the prize
As a sysadmin who deals with SCSI-based servers, I'm with Alan Cox on this: it's important to be able to ask for a device by SCSI device ID and LUN, numbers which are generally displayed on the physical unit. The existence of devices and controllers that don't fit this model does not make the old-style ones disappear.
Device name changing
I have a memory of removing one of my SCSI disks (I have 4 on the same bus) and the other disks changing their device names, is this the supposed behaviour. This is somewhat unexpected behaviour, but as Linus says, it might be difficult to implement otherwhise.
Not really...
consider dual attached devices... The numbering depends on how the
controller farm can relable them. Dynamic substitutions like this can
replace "unit 1" with "unit 2" at the drop of a hat. Even worse, it
could have been unit 1 from rack 1 and unit 1 from rack 2....
Now WHICH disk is the bad one?
The HOST doesn't have any way to know. You have to query the remote
raid controller, which doesn't necessarily respond over the same SCSI...
One I used (briefly) would only tell the administrative PC, attached to a control network that was attached to 30 controllers...
All the host could do is say "something happened".
Generally...
It's the one with the failed light on - this ain't the 90's. Please get out of the dark ages, when disks fail in an array, they now have a sexy amber/red light that lets even the dumbest tech swap the right one out. I know - we have support contract with dell and even they get it right :)
All my supermicro servers don
All my supermicro servers don't have such lights.
Then perhaps you should inves
Then perhaps you should invest in a real server with a hot swap cage and hardware status indicators that actually mean something.
Uh, is Linux supposed to be d
Uh, is Linux supposed to be designed for use with hardware that people actually own, or hardware that people wish they owned?
neither; it's designed for wh
neither; it's designed for what Linus Torvalds thinks you should own
> It's the one with the faile
> It's the one with the failed light on
An anecdote on this: as I'm colorblind I cannot see which is the red light or which is the green light in our disk array, so I have to ask someone to go with me in the server room..
*Sigh* what's wrong with blinking LEDs??
Stupid maker, color blindness isn't rare..
There's always a digital came
There's always a digital camera and using gimp's eye dropper tool to tell you if its more green then red :)
Not just about disk failure
The disk might not have failed - you could want to remove a disk for totally non-technical reasons, in which case you need to be able to identify it.
Some arrays let you get a specified disk to flash for identification purposes, but the OS should not be designed on the assumption that all arrays offer this functionality.
Yes really
As I said, the existence of devices that don't fit the common model I described does not eliminate the existence of devices that do. And single-attached devices are a lot more common than dual-attached devices.
But SAS is here, and cheap Po
But SAS is here, and cheap Port Selector dongle board would make any SATA drive into dual port device.
By the way, SCSI is dead, SAS is the next move. In SAS cloud, with a bunch of expanders wired up to 127 level of depth and variant horizental segments on each level, LUN is almost useless for mapping a device.
And say good bye to pre-assigned and safe LUN when dealing with this kind of expander chassis, because, they have none, except the well known one, 0; the worldwide unique name plus routing table is the mechanism for loacting devices.
I think you meant "*SCSI Para
I think you meant "*SCSI Parallel Interface* is dead" though there is plenty evidence to the contrary. SPI, SAS, iSCSI, Fibre Channel, and others are SCSI transport interfaces.
Going back to the original debate, there should be a separate mechanism for IDing devices on their specific transport medium for management purposes rather than programatic purposes. The current adapter/channel/target/lun system has lost all relevance even for the various SCSI transports (I'm not even getting started on pseudo lowlevel SCSI drivers for ATAPI, USB storage, etc). Maybe SCSI_IOCTL_GET_PCI should be reassigned to an IOCTL that provides transport-specific ID information (ex. SCSI_IOCTL_GET_TRANSPORT_ID) but behaves more like SCSI_IOCTL_PROBE_HOST in that it is just a pretty print string. There would be no guarantee of programatic value, but it certainly would help for physically managing the device. (that was a shot from the hip, I'm sure that someone has found programatic value in the SG_GET_SCSI_ID IOCTL)
I see the point
I understand the point Linus is making -- he is drawing a line at kernel responsibility - but the issue of scsi/lun id is truely an operational problem - it can be solved by mount by label in some situations(for example) - though I've found myself doing *kludgy* - feeling - things like not loading hba drivers until after discovery of internal drives - I suppose though I'm with him that this is a userspace issue (there are *gasp* commercial (!!) products to address this (as all prob know) as well as other ways native to specific to certain distros -- still I see that this would be inappropriate from the kernel-purity viewpoint
The jumper plug setting has real meaning
Maybe I'm missing a point here someplace. I'm no kernel hacker.
But if I set the jumper plugs on the bottom of my boot drive to SCSI address 0, and the jumpers on the drive that holds /home to SCSI address 3, and I plug both drives into the cable coming out of SCSI controller 0 on the motherboard, and I edit /etc/fstab to tell the system to mount /dev/sdb2 as /home, then I damn well want a dead-nuts certain way to tell the kernel at boot time that /dev/sdb equates to controller 0, SCSI address 3, always and forever, never mind what hotplug events occur or whether anything is set to addresses 1 and/or 2.
Agreed that not every device that looks to the system like a SCSI drive really is one. But some devices really are. And the whole point of jumper plugs and bit switches is to stop the system from screwing around with physical addresses.
Yes, you like totally missed
Yes, you like totally missed the point.
What you are talking about has *nothing* to do with the proposed ioctl.
If you want to mount things by topology, then mount things like:
/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host0/target0:0:0/0:0:0:0/block:sda/dev
True.
True.
Linus/friends want to remove the broken SCIC logic from applications. And only "certain cdrecord authours" can disagree with that.
Unix way to manage devices is by special file - device node. This way admins can manage who has access to which device.
The way "certain cdrecord authours" want - direct access to the bus, but not particular device - actually forces you to be root to use the application. Not the best idea...
Why people still cannot get it? It was true before devfs/sysfs - there were no way to access devices by topology. Now there is one. Use it if you want it. But don't expect everyone else to like that.
Two sides of the issue
Having spent the last 19 years as a Unix Sys-Admin, I have seen both sides of the story...
Sun systems, for instance, still preserve the c2t1d0s3 semantics but it does so through symlinks, eg:
c0t8d0s3 -> ../../devices/pci@1f,4000/scsi@3/sd@8,0:d
I would actually prefer that the system maintain some sense that c0 is "/devices/pci@1f,4000/scsi@3". Yes, it's shorthand, but shorthand is a good thing.
Linus does have a point, however, as the enumeration of controllers/devices is arbitrary. Set up a software raid volume using Solaris' DiskSuite, remove an unneeded controller, do a "boot -r" and you'll find you can't mount your raid volume because things have been renumbered.
But sometimes the point is on Linus' head. I have 4 identical fibre-channel arrays spread across 4 identical controllers. These four arrays/luns are indisinguishable except by WWN. Now when I have two failures in different arrays, how do I determine which failure is associated with which physical device?
It turns out that the fastest way to determine this (including the sd[a-z]->controller mapping) is to
for disk in /dev/sd[a-z] do dd count=100000 if=${disk} of=/dev/null doneand then watch the blinking lights. This is sooo wrong, and isn't particularly ADA-compliant. What if you don't have blinky lights?
And Linus reveals something important in his statements
Note how, for example, this says 0:0:0:0, which happens to be the controller/channel/id/lun information for that "SCSI device". Notice how it is all zeroes? It's because that whole concept doesn't make any sense for things like USB storage, which has a totally different way to address the things.If the semantics for "things like USB storage" don't make sense as a SCSI device, then why the hell was it put in there in the first place?
Shoving round pegs in square holes and then complaining about square pegs just doesn't make sense. You have the power tools, go make your own round hole.
USB storage does make sense as a SCSI device
USB storage is a SCSI command over USB transport definition (same point in the SCSI stack as SPI, FC or SAS). What's being requested is that all SCSI transports enumerate themselves using SPI-style Controller-DeviceID-LUN numbering. This is fine for SCSI transports with similar concepts (like SAS, but even that's problematic, as SAS uses much larger datatypes for device id and LUN), but useless for SCSI transports like SBP-2 and USB storage. Further, there is this idea that it should be possible to open a fixed device name (e.g. /dev/sg0), and use SPI-style naming from then on; a slight generalisation is the idea that all SCSI devices should have a corresponding /dev/sg*, and each /dev/sg* should know its SPI-style address. Either way, it's forcing transports to behave like SPI, even when that makes no sense.
The other alternative (which you seem to be advocating, hopefully from lack of research) is for each SCSI transport to carry around an entire SCSI stack, rather than have them share a single SCSI stack. This is the approach taken in writing the ub USB storage driver; the result is that ub only supports a very small subset of the available SCSI commands (basically those needed for USB-attached disks). I'm sure that you can see how stupid it would be for Linux to treat SAS disks completely differently from SPI disks (which in turn would be treated completely differently from FC disks), with completely different sets of available functionality, when the only real issue is that some SCSI transports don't have SPI-type addressing.
As you point out yourself, there is already a way for administrators to work with the (transport specific) device identifiers. You go through the /sys/devices tree, locating the controller by PCI bus and logical slot number, then into the SCSI host on that device, then into the target (by device id, LUN, or whatever else is reasonable). udev provides the tools you need to create /dev nodes based on this information, without carrying around the full device path. This lets you, the administrator, decide that, on your system, devices will be named things like /dev/c0t8d0s3sg rather than /dev/sg0, or even that the device is /dev/pci/domain0000/bus0/device0d/host8/target0/lun3, with a symlink from /dev/c0t8d0s3 to that device node. I can decide that I prefer /dev/dvdrom and /dev/dvdwriter. Programmers just need that device name to do everything they need to do, except determine the SPI-style address of the device.
This also has advantages for things like ATAPI over SATA, which is a limited SCSI over SATA (but not for disk-type block devices). They can fake a device that looks like a SCSI device to a program, but which has no meaningful idea of an SPI address. The programmer doesn't have to write their code lots of times (once for SCSI, once for ATAPI, once for whatever other methods are provided); instead they just use the device provided.
"SPI Layer"
So put the ioctl in the "SPI layer". Oh, wait, there isn't a way to do that, is there? So why not put it in the SCSI layer and have it return an error for other transport layers?
What's the ioctl supposed to do, exactly?
And what do you expect this ioctl to do that can't be done better via sysfs and device nodes? It can't make it easier to point an admin at a device; device nodes do that already, and the admin defines the relationship between device nodes and physical devices themselves. It can't make it easier to get the device details for an admin; the admin should find it easier to know that the DVD burner is /dev/dvdburner than that it's PCI domain 0, PCI bus 0, PCI card number 12, PCI function 2, Bus 5, Target 12, LUN 0, or that /dev/raid/left-array/top-disk (which is PCI domain 1, PCI bus 2, PCI card 1, PCI function 0, Bus 1, Target 0, LUN 5) is the topmost disk in the left-hand RAID array. It can't make it easier to open a specified device by ID; you can do that by constructing a sysfs path (which also gets you non-SPI SCSI devices, if that's what you'd like to do). If you do genuinely need the SPI address of the device, you can start with the device node the admin passes you, and walk the sysfs tree until you find it.
In short, you're proposing that the kernel be made more complex to solve a non-problem. You need to present a case where the mechanisms provided by Linux make something impossible, or at least make a common, sane program much more complex than it has to be. Thus far, the only justification I've seen for demanding that the SCSI layer know the SPI addresses of devices on a SCSI bus is the claim that another OS does it that way. This is not a good justification; find a use case which is both sane in a Linux-only world, and which cannot be sanely implemented with the kernel's current mechanism.