From: Martin Dalecki <dalecki@evision-ventures.com>
To: ptb@it.uc3m.es
Cc: linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: what is teh current meaning of blk_size?
Date: Mon, 12 Nov 2001 21:51:42 +0100 [thread overview]
Message-ID: <3BF0365E.46DAABB0@evision-ventures.com> (raw)
In-Reply-To: <200111121939.UAA04358@nbd.it.uc3m.es>
"Peter T. Breuer" wrote:
>
> Is blk_size[][] supposed to contain the size in KB or blocks?
>
> I'm confused because it looks to me as though it's still in KB,
> but people say that devices can be up to 8 or 16TB, and there's
> not enough room for that within a signed int containing KB
> (2^31 * 2^10 = 2^41 = 2TB).
>
> Either the rumour is true and it's in blocks, or the rumour
> is false and it's in KB.
>
> Clue, please!
There is no rumor it's in blocks.
There are three level of block size measurements in linux:
1. FS level one. (page chunks most of time main exceptions are dos and
isofs)
2. Driver level one. (nearly always 1024, main exception are ATAPI
cdrom)
3. Hardware device level one. (nearly always 512, only prehistoric SCSI
drives from the stone age are exceptional and providing 256 byte sized
block. We discovered them druing our archeological efforts recently
under
a thick layer of mood...)
It's left as an exercies to the reader which one of the sparse
matrices in ll_rw_blk.c is declaring which ;-).
...
OK I was to fast to figure it out:
/*
* blk_size contains the size of all block-devices in units of 1024 byte
* sectors:
*
* blk_size[MAJOR][MINOR]
*
* if (!blk_size[MAJOR]) then no minor size checking is done.
*/
int * blk_size[MAX_BLKDEV];
/*
* blksize_size contains the size of all block-devices:
*
* blksize_size[MAJOR][MINOR]
*
* if (!blksize_size[MAJOR]) then 1024 bytes is assumed.
*/
int * blksize_size[MAX_BLKDEV];
/*
* hardsect_size contains the size of the hardware sector of a device.
*
* hardsect_size[MAJOR][MINOR]
*
* if (!hardsect_size[MAJOR])
* then 512 bytes is assumed.
* else
* sector_size is hardsect_size[MAJOR][MINOR]
* This is currently set by some scsi devices and read by the msdos fs
driver.
* Other uses may appear later.
*/
int * hardsect_size[MAX_BLKDEV];
read_ahead there is a blunt - it's a "write only array anyway"....
Initialize
it to the system default and don't care.
next prev parent reply other threads:[~2001-11-12 19:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-12 19:39 what is teh current meaning of blk_size? Peter T. Breuer
2001-11-12 20:51 ` Martin Dalecki [this message]
2001-11-12 22:10 ` Peter T. Breuer
-- strict thread matches above, loose matches on Subject: below --
2001-11-13 15:08 Peter T. Breuer
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=3BF0365E.46DAABB0@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=dalecki@evision.ag \
--cc=linux-kernel@vger.kernel.org \
--cc=ptb@it.uc3m.es \
/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