Importance: Normal
Subject: Re: Re: Hardsector size support in 2.4 and 2.5
To: dalecki@evision.ag
Cc: linux-kernel@vger.kernel.org, evms-devel@lists.sourceforge.net
Message-ID: <OF9F38B076.0F9781F3-ON85256B02.006D5DFE@raleigh.ibm.com>
From: "Mark Peloquin" <peloquin@us.ibm.com>
Date: Mon, 12 Nov 2001 14:05:19 -0600
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org

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?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/