public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: linux-kernel@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] SG_IO readcd and various bugs
Date: Sun, 01 Jun 2003 17:39:49 +1000	[thread overview]
Message-ID: <3ED9ADC5.7060006@torque.net> (raw)
In-Reply-To: <20030531105742.GC9561@suse.de>

Jens Axboe wrote:
> On Sat, May 31 2003, Douglas Gilbert wrote:

>>With the latest changes from Jens (mainly dropping the
>>artificial 64 KB per operation limit) the maximum
>>element size in the block layer SG_IO is:
>>  - 128 KB when direct I/O is not used (i.e. the user
>>    space buffer does not meet bio_map_user()'s
>>    requirements). This seems to be the largest buffer
>>    kmalloc() will allow (in my tests)
> 
> 
> Correct.
> 
> 
>>  - (sg_tablesize * page_size) when direct I/O is used.
>>    My test was with the sym53c8xx_2 driver in which
>>    sg_tablesize==96 so my largest element size was 384 KB
> 
> 
> Or ->max_sectors << 9, whichever is smallest. Really, the limits are in
> the queue. Don't confuse SCSI with block.

The block layer SG_IO ioctl passes through the SCSI
command set to a device that understands it
(i.e. not necessarily a "SCSI" device in the traditional
sense). Other pass throughs exist (or may be needed) for
ATA's task file interface and SAS's management protocol.

Even though my tests, shown earlier in this thread, indicated
that the SG_IO ioctl might be a shade faster than O_DIRECT,
the main reason for having it is to pass through "non-block"
commands to a device. Some examples:
   - special writes (e.g. formating a disk, writing a CD/DVD)
   - uploading firmware
   - reading the defect table from a disk
   - reading and writing special areas on a disk
     (e.g. application client log page)

The reason for choosing this list is that all these
operations potentially move large amounts of data in a
single operation. For such data transfers to be constrained
by max_sectors is questionable. Putting a block paradigm
bypass in the block layer is an interesting design :-)

With these patches in place cdrecord (in RH 9) works via
/dev/hdb (using ide-cd). Cdrecord fails on the same ATAPI
writer via /dev/scd0 because ide-scsi does not set max_sectors
high enough [and the SG_SET_RESERVED_SIZE ioctl reacts
differently in this case to the sg driver].

In summary, I see no reason to constrain the SG_IO ioctl
by max_sectors. SG_IO is a "one shot" with no command
merging or retries. If the HBA driver doesn't like a command,
then it can reject it. [However, currently there is no
mechanism to convey host or HBA driver errors back through
the request queue, only the device (response) status.]

Doug Gilbert



  reply	other threads:[~2003-06-01 12:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-31  8:23 [PATCH] SG_IO readcd and various bugs Douglas Gilbert
2003-05-31 10:57 ` Jens Axboe
2003-06-01  7:39   ` Douglas Gilbert [this message]
2003-06-02  7:27     ` Jens Axboe
2003-06-03  5:23       ` Douglas Gilbert
2003-06-03  5:39         ` Nick Piggin
2003-06-03  8:29         ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2003-05-30 13:02 Jens Axboe
2003-05-30 13:47 ` Markus Plail
2003-05-30 13:52   ` Markus Plail
2003-05-30 14:58     ` Jens Axboe
2003-05-30 16:57       ` Markus Plail
2003-06-01  7:50         ` uaca
2003-06-01  9:18           ` Markus Plail
2003-06-01 10:19             ` uaca

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ED9ADC5.7060006@torque.net \
    --to=dougg@torque.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox