Re: [PATCH] libata: device suspend/resume

Jeff Garzik
2005-05-24T17:10:05Z

Douglas Gilbert wrote:
> At the risk of boring you but informing others, Serial
> Attached SCSI (SAS) is going to muddy things.

Not necessarily... ;-)

But yes, I am keeping track of SAS, don't worry.

> The SCSI ATA Translation (SAT
> http://www.t10.org/ftp/t10/drafts/sat/sat-r04.pdf )
> draft hopefully will find application any many areas
> other than libata (e.g. USB mass storage and 1394's
> SBP-2 drivers). The Scope section (section 1) of that
> draft makes interesting reading: in point a) the author
> sees SAT as presenting a unified command interface for
> block type devices across PATA, SATA and ATAPI!

In Linux's case, libata's SCSI<->ATA translation is merely a convenience
so that I didn't have to bother writing all that storage infrastructure
at the block layer. And SAT was merely a convenient standard I could
follow during the exercise.

> However the primary reason that SAT started is the
> fact that SAS infrastructure can include SATA disks.
> SAS defines the Serial ATA Tunneled Protocol (STP)
> which in linux will first appear in a SAS LLD (i.e.
> a scsi subsystem Low Level Driver, something like
> aic7xxx). Connecting a SATA disk (transported via SAS)
> to the IDE subsystem and a /dev/hd? device node seems
> like an unnatural act (a bit like ide-scsi in reverse).
> A solution involving libata seems appropriate in this case.

Certainly there will be hardware that attaches to both SATA and SAS.
I've been planning for this. I even have an Adaptec card (and docs).

It depends highly on the LLD how this is implemented. If a SCSI
interface to SATA is forced upon us (i.e. SAT is implemented in a
firmware somewhere), then there's not much you can do.

If the LLD provides direct access to either SCSI CDBs or ATA taskfiles
(FIS's), then the OS should directly work with the device's native
command set. Far from adding value, translation actually hinders
progress, as users must either (a) find a way around the SAT layer to
access an ATA feature, or (b) wait until the SAT layer is updated to
support a translation for the desired feature.

One of the biggest requested features for libata is "ATA passthru", the
ability to directly submit ATA commands to the device. That should tell
you something about what -users- want.

SCSI and ATA are competing and evolving command sets, which implies that
there is -increased- interest in -not- hiding ATA devices behind an
emulation layer.

A SATA+SAS LLD would ideally register an instance of the SAS transport
class with the SCSI layer, and an instance of the SATA transport class
with the block layer. That's all it needs to do.

Everything else -- /dev/hdX versus /dev/sdX, emulation, sd/sr/st, etc.
-- are all clients to either a SATA or SCSI transport class. Remember,
to many users, the fact that SATA right now uses /dev/sdX is confusing
and annoying: they would prefer /dev/hdX as IDE has been presenting for
over a decadce.

With the right design, there is little value OR NEED in hiding ATA
devices behind emulation.

> Even more likely is that a SAT layer will be implemented
> in SAS enclosures just inches away from lots of SATA
> disks. From the point of view of a linux machine
> such SATA disks talk the SCSI command set and are
> connected via a SAS transport (Serial SCSI Protocol (SSP)).
> The only things that will probably care about the
> difference between such SATA disks and SAS disks are
> utilities like smartmontools (and that gap is being
> partially closed as well).

Linux will always want to talk to a device in its native command set,
unless a firmware _forces_ us to do otherwise.

If the user considers a SAT layer added value, then they can certainly
use such at their site.

> Perhaps libata could be renamed libsat.

s/libata/libata-scsi/

libata core is a SCSI-independent ATA transport, approaching the "ATA
transport class" that I described above.

Jeff