From: Jens Axboe <axboe@suse.de>
To: Douglas Gilbert <dougg@torque.net>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>, alan@redhat.com
Subject: Re: sg driver and Fedora Core 2
Date: Fri, 28 May 2004 16:18:54 +0200 [thread overview]
Message-ID: <20040528141854.GJ20657@suse.de> (raw)
In-Reply-To: <40B74725.90403@torque.net>
On Sat, May 29 2004, Douglas Gilbert wrote:
> Recently I have had a query about how a specialist application
> (that worked in the lk 2.4 series) sends 16 MB data through a
> single SCSI command in Fedora Core 2. The simple answer to that
> one is the block layer imposes a 128 KB limit on single
> transfers and that's it. [Counter-intuitively that limit also
> applies to st and osst when they use the SG_IO ioctl.] Around a
> year ago I tried to move Jens Axboe on this issue and failed.
> Evidentally there are good reasons why the block layer imposes
> that limit. There are other issues with this change.
The block layer does not impose any 128KB limitation. In fact there
should be no real limitations (*). The block layer honors whatever
restrictions that the drivers sets, 128KB is the maximum transfer size
for an ATAPI drive for instance.
You could flag queue capability to handle requests > max_sectors like
SCSI has always been able to. Then you could change this check
if (hdr->dxfer_len > (q->max_sectors << 9))
return -EIO;
to only fail for drivers that can't partially complete requests
correctly. This would allow such applications to continue working.
(*) Not quite true, since the max size of a bio is 1MB on 4KB page sized
hardware. You can string them for bigger total size, though.
>
> There seems to be mixed signals coming from the Fedora camp
> on this change. A "policy" change was one response and this
> url ( http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123876 )
> has Alan Cox stating that this change is a bug.
That's not the identical issue, it's due to usb storage setting 120KB as
the max size causing sg_set_reserved_size() to fail.
--
Jens Axboe
next prev parent reply other threads:[~2004-05-28 14:19 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-28 14:05 sg driver and Fedora Core 2 Douglas Gilbert
2004-05-28 14:18 ` Jens Axboe [this message]
2004-05-28 14:28 ` Jens Axboe
2004-05-28 17:25 ` Alan Cox
2004-05-29 15:55 ` James Bottomley
2004-05-29 15:57 ` Alan Cox
2004-05-29 16:07 ` James Bottomley
2004-05-29 16:29 ` Alan Cox
2004-05-29 16:36 ` Arjan van de Ven
2004-05-29 16:42 ` Alan Cox
2004-05-29 17:45 ` Matthew Wilcox
2004-05-29 16:49 ` James Bottomley
2004-05-29 16:56 ` Alan Cox
2004-05-29 17:28 ` James Bottomley
2004-05-29 17:38 ` Alan Cox
2004-05-29 17:27 ` Jeff Garzik
2004-05-29 17:29 ` Jens Axboe
2004-05-30 10:37 ` Douglas Gilbert
2004-05-30 10:41 ` Alan Cox
2004-06-07 8:56 ` Douglas Gilbert
2004-05-29 17:35 ` Alan Cox
2004-05-29 17:42 ` Jeff Garzik
2004-05-29 17:38 ` James Bottomley
2004-05-29 17:46 ` Alan Cox
2004-05-29 17:58 ` Jeff Garzik
2004-05-30 10:20 ` Jens Axboe
2004-05-29 16:24 ` Arjan van de Ven
2004-05-28 17:39 ` Arjan van de Ven
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=20040528141854.GJ20657@suse.de \
--to=axboe@suse.de \
--cc=alan@redhat.com \
--cc=dougg@torque.net \
--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