From: "Mark Peloquin" <peloquin@us.ibm.com>
To: dalecki@evision.ag
Cc: linux-kernel@vger.kernel.org, evms-devel@lists.sourceforge.net
Subject: Re: Re: Hardsector size support in 2.4 and 2.5
Date: Mon, 12 Nov 2001 14:05:19 -0600 [thread overview]
Message-ID: <OF9F38B076.0F9781F3-ON85256B02.006D5DFE@raleigh.ibm.com> (raw)
Martin Dalecki wrote:
> > I was wondering if 2.5 will *really* support different hard sector
> > sizes. Today the hardsect array in the kernel seems to serve
> > little purpose. Drivers fill it in, but then what? It does not appear
> > to be used in any io path computations as illustrated by code
> > in submit_bh and generic_make_request which use a few
> > hardcoded shifts by 9 when dealing with sector sizes.
> >
> > Is the hardsect array on the way *in* or the way *out* of the
> > kernel? Will 2.5 take the real hardsector value into account?
> > Or can we expect everything to be handled in 512 byte
> > multiples (as we do today)?
> It is on it's way out, since:
That is good, then the code should be less confusing.
> 1. Most hardware sec sizes are obscelny lower that the minimal logical
> sizes those days (512 ver. 4096 page size),
> so the tuning there doesn't matter.
> 2. All of it is "tuning", which can be handled generically on higher
> levels. (Like setting FS blocksize....)
> 3. The hard limits are handled on device driver level anyway (best
> example here are the odd fs block sizes for iso9660 filesystem).
So any block device, can always expect to receive buffer heads
whose b_rsector value represents the offset from the beginning
of that device in 512 byte multiples? And this will continue
to hold true in 2.5 as well?
next reply other threads:[~2001-11-12 20:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-12 20:05 Mark Peloquin [this message]
2001-11-12 20:27 ` [Evms-devel] " Christoph Hellwig
2001-11-13 9:02 ` Jens Axboe
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=OF9F38B076.0F9781F3-ON85256B02.006D5DFE@raleigh.ibm.com \
--to=peloquin@us.ibm.com \
--cc=dalecki@evision.ag \
--cc=evms-devel@lists.sourceforge.net \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®