All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dougg@torque.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de>,
	linux-kernel@vger.kernel.org, jens.axboe@oracle.com,
	James.Bottomley@steeleye.com
Subject: Re: [PATCH] Block layer: separate out queue-oriented ioctls
Date: Mon, 19 Feb 2007 23:47:51 -0500	[thread overview]
Message-ID: <45DA7D77.9020709@torque.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0702192238110.4237-100000@netrider.rowland.org>

Alan Stern wrote:
> On Mon, 19 Feb 2007, Douglas Gilbert wrote:
> 
>> Alan,
>> The SG_GET_RESERVED_SIZE ioctl is also defined in
>> the block layer, see block/scsi_ioctl.c .
> 
> Ah, I didn't know that.  (Or more likely, I used to know and have since 
> forgotten.)  Thanks for pointing it out.
> 
>> I suspect it is just a kludge to fool cdrecord that it
>> is talking to a sg device. [One of many kludges in the
>> block SG_IO ioctl implementation to that end.]
>> So perhaps the block layer versions of SG_SET_RESERVED_SIZE
>> and SG_GET_RESERVED_SIZE need to be similarly capped.
> 
> Yes.  In fact one of them already is, but the other should be too.
> 
>> Actually I think that I would default SG_GET_RESERVED_SIZE to
>> request_queue->max_sectors * 512 in the block layer
>> implementation (as there is no "reserve buffer" associated
>> with a block device).
> 
> Okay.
> 
> Come to think of it, the reserved_size value used when a new sg device is
> created should also be capped at max_sectors * 512.  Agreed?  I can't see
> any reason for ever having a larger buffer -- it would be impossible to
> make use of the extra space.

Alan,
That depends whether or not max_sectors can be changed
(via sysfs) subsequent to a sg device being created.
And I think it can.

# ls -l /sys/block/sdc/queue/
total 0
drwxr-xr-x 2 root root    0 Feb 19 18:29 iosched
-r--r--r-- 1 root root 4096 Feb 19 23:41 max_hw_sectors_kb
-rw-r--r-- 1 root root 4096 Feb 19 23:41 max_sectors_kb
-rw-r--r-- 1 root root 4096 Feb 19 23:41 nr_requests
-rw-r--r-- 1 root root 4096 Feb 19 23:41 read_ahead_kb
-rw-r--r-- 1 root root 4096 Feb 19 23:41 scheduler


# cat max_hw_sectors_kb > max_sectors_kb

... is the real maximum if the LLD that set max_hw_sectors_kb
is to be believed (actually it is often a finger in
the wind).

Doug Gilbert



  reply	other threads:[~2007-02-20  4:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16 19:37 [PATCH] Block layer: separate out queue-oriented ioctls Alan Stern
2007-02-17  6:28 ` Jens Axboe
2007-02-17 21:18   ` Joerg Schilling
2007-02-18  3:43   ` Douglas Gilbert
2007-02-18 12:37     ` Joerg Schilling
2007-02-18 16:44     ` Alan Stern
2007-02-18 18:27       ` Joerg Schilling
2007-02-19 16:06         ` Alan Stern
2007-02-19 16:08           ` Joerg Schilling
2007-02-19 17:06             ` Alan Stern
2007-02-19 22:25               ` Douglas Gilbert
2007-02-20  3:48                 ` Alan Stern
2007-02-20  4:47                   ` Douglas Gilbert [this message]
2007-02-20 15:55                     ` Alan Stern
2007-04-26  9:19                 ` Joerg Schilling
2007-04-26 15:04                   ` Alan Stern
2007-04-26 15:08                     ` James Bottomley

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=45DA7D77.9020709@torque.net \
    --to=dougg@torque.net \
    --cc=James.Bottomley@steeleye.com \
    --cc=Joerg.Schilling@fokus.fraunhofer.de \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.