From: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Michael Reed <mdr@sgi.com>,
linux-raid@vger.kernel.org, neilb@suse.de,
Jeremy Higdon <jeremy@sgi.com>, Hannes Reinecke <hare@suse.de>
Subject: Re: md question re: max_hw_sectors_kb
Date: Wed, 04 May 2011 20:08:02 +0200 [thread overview]
Message-ID: <4DC19602.9060401@itwm.fraunhofer.de> (raw)
In-Reply-To: <yq17ha6z6tu.fsf@sermon.lab.mkp.net>
On 05/04/2011 07:58 PM, Martin K. Petersen wrote:
>>>>>> "Michael" == Michael Reed<mdr@sgi.com> writes:
>
> Michael> There is code in blk_queue_make_request() which lowers the
> Michael> default value from INT_MAX to BLK_SAFE_MAX_SECTORS, which is
> Michael> 255. This is generally lower than all the underlying devices
> Michael> with which I use md.
>
> Yeah, the SAFE value is there to appease legacy low-level drivers.
>
>
> Michael> As md appears to be a stacking driver, i.e., it calls
> Michael> disk_stack_limits() for each member of a volume, it would seem
> Michael> reasonable for md to use the, INT_MAX setting for
> Michael> max_hw_sectors_kb instead of BLK_SAFE_MAX_SECTORS.
>
> Your fix is functionally correct. However, another case just popped up
> this week where we need to distinguish between stacking driver and LLD
> defaults. So I think we should try to handle this at the block layer
> instead of explicitly tweaking this knob in MD.
>
> I'll get this fixed up and will CC: you on the patch.
>
Could you please CC me or linux-raid as well? I have a similar patch for
raid1 and while I'm not working on Lustre anymore, I know that Lustre
also always has a another kernel patch for raid5...
Thanks,
Bernd
next prev parent reply other threads:[~2011-05-04 18:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 20:20 md question re: max_hw_sectors_kb Michael Reed
2011-05-04 17:58 ` Martin K. Petersen
2011-05-04 18:08 ` Bernd Schubert [this message]
2011-05-09 23:52 ` NeilBrown
2011-05-12 3:51 ` Martin K. Petersen
2011-05-31 3:06 ` fibreraid
2011-05-06 4:24 ` NeilBrown
2011-05-06 4:40 ` NeilBrown
2011-05-09 16:02 ` Michael Reed
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=4DC19602.9060401@itwm.fraunhofer.de \
--to=bernd.schubert@itwm.fraunhofer.de \
--cc=hare@suse.de \
--cc=jeremy@sgi.com \
--cc=linux-raid@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mdr@sgi.com \
--cc=neilb@suse.de \
/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.