Re: [RFC] SAS domain layout for Linux sysfs

From: Luben Tuikov
Date: Mon Apr 25 2005 - 11:22:41 EST


On 04/24/05 07:19, Christoph Hellwig wrote:
>
> This is contrary to any sysfs topology I know about, especially any
> existing transport class (SPI, FC, iSCSI).

This RFC is about SAS.

> We only ever care about what's seen from a HA,

Imagine you could connect to the same device via two
different PCI controllers on the same host.

> e.g. if you have muliple SPI cards that are
> on a single parallel bus you'll have the same bus represented twice,
> similarly if you have two fibre channel HBAs connected to the same
> SAN you'll have the SAN topology duplicated in both sub-topologies.

Hmm, this proposal is for SAS only, Christoph.

If you have multiple SAS host adapters connected to the same
SAS domain, the _path_ they connect to a SAS device may be _different_.
But what is the same is the SAS domain (topology) itself *regardless of
how you connect to it.*

In order to eliminate duplication of sysfs entries (directories
and files) to describe the same SAS device, we split up the
representation into a "flat" directory with just a bunch
of SAS devices, this is /sys/bus/sas/. And the way you _connect_
to those SAS devices is represented in sys/class/sas_ha/.

See this (new) picture:
| |
+-------+ | |
|ha0 [] =--|-----------. |
+---||||+ | \ +-----+ |
| `-= ex2 =--|--> ta0
| | =--|--> in2
| .-= =--|--> ta2
+-------+ | +-----+ / +-----+ |
|ha1 [] =--|--= ex1 =--' |
+---||||+ | +-----+ |
| |
Host domain| Sysfs SAS domain only | Both domains

Anything *but* "Host domain" is "out there" and *doesn't
change* regardless of how you connect to it.

What changes is *how you connect* to to SAS devices from
your host (the host domain).

In effect ta0, in2, ta2, ex1, ex2 are represented only *once*,
in /sys/bus/sas/. But the way your host adapter connects to
them is described in /sys/class/sas_ha/, with the appropriate
symbolic links as described in the RFC.

Luben


> This matches the internal data structure of the scsi subsystem and
> the transport class, e.g. we have a scsi_device object for every lun
> that's seen from a hba, linked to the HBAs Scsi_Host object and not
> one shared by multiple HBAs. Dito for fibre channel remote ports.
>
>
> One note to this proposal: it probably doesn't make a lot of sense to
> try to flesh out the sysfs topology before doing the kernel internal
> object model as the former pretty much follows the latter.
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/