Re: Help - SCSI passthrough ioctl calls vs. sd/sg devices

From: Josef Möllers (josef.moellers_at_fujitsu-siemens.com)
Date: 04/22/04 

Date: Thu, 22 Apr 2004 09:28:10 +0200

L wrote:
> Hi,
>
> I would appreciate it if some one could clarify this. It's a bit confusing.
>
> <<The Linux SCSI Generic (sg) HOWTO>> page 2 says "The sg driver permits
> user applications to send SCSI commands to devices that understand them.
> SCSI commands are 6, 10, 12 or 16 bytes long. The SCSI disk driver (sd),
> once device initialization is complete, only sends SCSI READ and WRITE
> commands."
>
> <<The Linux 2.4 SCSI subsystem HOWTO>> page 3 says "Sg is a SCSI command
> pass through device that uses a char device interface. General purpose
> Linux commands should not be used on sg devices."
>
> My questions are:
>
> - sounds like SCSI passthrough ioctl calls can only apply
> to sg devices. Is it right, or can we apply SCSI
> passthrough ioctl calls to sd devices as well?

Each SCSI device found by the SCSI mid-layer is assigned an sg device.
If it happens to be a Direct-Access device, it will also be assigned an
sd device, if it is a Sequential-Access device, it will also be assigned
an st device.
So: each sd device also has an associated sg device. As a rule of thumb,
I always scan /proc/scsi/scsi and "mentally" assign an sg device to each
SCSI device found and an sd device to each Direct-Access device found. I
was told that this algorithm is not generally safe, e.g. if you remove
and add devices by hand.

> - what are the so-called "General purpose Linux commands"?
> Are they read()/write() or 'mount' / 'dd' or something else?

A command is a command, e.g. cp, cat, dd, mount. You can dd from/to
/dev/sda but you cannot dd from/to /dev/sg1.

System calls are used to access sg devices, you'll have to open(2)
/dev/sg..., the use ioctl(2) (or write(2)/read(2) with the old
interface) to issue commands, the close(2) the device afterwards.

> What should we do if we need to 'mount' a file system on a disk and also
> need to issue SCSI passthrough ioctl calls to the same disk? Maybe we
> should use both sd and sg (i.e. mount the file system to /dev/sda1, and
> issue SCSI passthrough ioctl calls to /dev/sg0 that maps to the same
> disk/lun)? I was told 'mount' doesn't work on sg devices, right?

Right, as stated above.
You can issue SCSI commands to a SCSI disk using the appropriate
/dev/sg... However, you must be veeeery carefully not to confuse the
disk driver! Better first issue the generic command(s), then mount the disk.

HTH,

Josef 

-- 
Josef Möllers (Pinguinpfleger bei FSC)
	If failure had no penalty success would not be a prize
						-- T.  Pratchett

Relevant Pages

  • [patch 02/33] m68k: Reformat the Atari SCSI driver
    ... NCR 5380 generic driver routines. ... SCSI Protocol Controller ... * commands were hacked on rather than designed in from the start. ... which is started when not running by the interrupt handler, ...
    (Linux-Kernel)
  • Re: Help - SCSI passthrough ioctl calls vs. sd/sg devices
    ... It's a bit confusing. ... > user applications to send SCSI commands to devices that understand them. ... You can issue SCSI commands to a SCSI disk using the appropriate ...
    (comp.os.linux.misc)
  • Re: Help - SCSI passthrough ioctl calls vs. sd/sg devices
    ... It's a bit confusing. ... > user applications to send SCSI commands to devices that understand them. ... You can issue SCSI commands to a SCSI disk using the appropriate ...
    (comp.os.linux.development.apps)
  • Re: Help - SCSI passthrough ioctl calls vs. sd/sg devices
    ... It's a bit confusing. ... > user applications to send SCSI commands to devices that understand them. ... You can issue SCSI commands to a SCSI disk using the appropriate ...
    (comp.os.linux.development.system)
  • Re: Linux SCSI programming
    ... I'm trying to write a Linux API that communicates to SCSI devices. ... then sending a ioctl() to the device. ... ReadFileand WriteFilecommands and I'm not sure how to accomplish ... Low level access should not be needed for data I/O (with ...
    (comp.periphs.scsi)