RE: [PATCH] minimal SAS transport class

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > This is a heck of a statement... The customers don't see it 
> as SAS vs FC
> > vs SPI, they just see it as SCSI, and there's a lot of 
> expectations on
> > consistent behavior. We take a lot of heat defending the community's
> > position, even from companies that you would have thought 
> had signed on
> > to the 2.6 behaviors.
> 
> I tried to understand this paragraph in the light of the very 
> few past days,
> but I couldn't.  What is it actually saying?
> 
> > I understand the need to push folks to the new 2.6 models, 
> but I fully
> > expect the same complaints to come from the users of SAS 
> and iSCSI as well.
> 
> What kind of complaints?
> 
> I ask because I'm a "user of SAS and iSCSI".

Ok, so I guess I owe you a response. I hesitate, as this discussion
always becomes larger than it should.

There are 2 key points:
- the target id is logical for everything but SPI
- following old SPI behavior, users expect the same devices to
  be enumerated at the same target ids, regardless of whether
  that enumeration is at the next link event, driver load/unload,
  or system reboot. The corollary for this is that the device's
  name should have remained the same as well.

For FC, target ids are typically assigned to devices on a
1st-seen-1st-assigned basis. For several reasons, there can be
changes in port discovery order after link events (cable pulls,
etc). For 2.4 kernels, the driver typically maintained a mapping
within the driver to ensure the same device showed up at the same
target id, even if it disappeared for some amount of time. If FC
was the boot device, wacky methods were used to ensure the mapping
persisted boot-to-boot.

For 2.6 kernels, the desire is to move away from relying on the
physical addressing. The recommendation is to use udev (preferred)
or filesystem labels (ok in some circumstances) to find the right
devices. By moving to lun/device-level id's, issues such as name
shift are better solved (note: name-shift still existed under 2.4).

We have found users having difficulty with the udev transition, as:
- From 2.4 history, old scsi behavior, and other unix's behavior
  (which functions much like 2.4), they are accustomed to not
  needing external tools or admin steps for device nameing.
  Things had just worked for the most part.
- Most view 2.6 as an upgrade and didn't expect something this
  basic to change.
- Many really don't know about or understand udev, hotplug,
  disk identifiers, and so on. Thus, there's a large education
  effort. It has to be dealt with in yet more documentation,
  help lines, etc.
- There are some real challenges in supporting a udev-named boot
  device. For the most part, it's a distro issue, which is becoming
  better. PS: for $10, name a 2.6 distro that uses udev out
  of the box for disk names and its installation. For $10 more, 
  can it install/boot from one?
- For better or worse, tools and api's exist that interacted with
  the old 2.4-style behavior. Now they must wait for the tools to
  be updated, suffer their non-functionality, and/or craft their
  own tools.
- Some of these vendors come from large disk farms, and in several
  cases, the disk farms change frequently. Thus, they must flush
  and regenerate their udev configurations on each change. Not a
  fun process.
- Most could care less about, or don't understand, the technical
  justifications for the new 2.6 behaviors. Thus, they push their
  vendors for same-style behaviors as 2.4 regardless of the 2.6
  stance.

Now - back to Christoph's point....

For iSCSI, (correct me if I'm wrong) as the scsi_host is mapped 1:1
with the session, there really is no such thing as multiple targets,
so it works. Even if it isn't 1:1, it is controlled via user space
so it's likely managable. Note: instead of target id shifting, there
may now be scsi_host number shifting.

For SAS, looking at Christoph's code - 
The target id comes from the LLDD. So either the LLDD maintains a
map of SAS port addresses to target ids, or the mapping could change,
same as FC. Christoph's argument is that FC's issue was historical.
SAS is sufficiently new that folks are now smart enough to use udev.
My contention is that people will expect the same behavior out of
SAS as they did w/ FC. To them its all "just SCSI".

I'm winded. Hope this helps.

-- james s
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux