mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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?


             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®