From: William Park <opengeometry@yahoo.ca>
To: linux kernel <linux-kernel@vger.kernel.org>
Cc: "Peter T. Breuer" <ptb@it.uc3m.es>,
Andreas Dilger <adilger@turbolabs.com>
Subject: Re: blocks or KB? (was: .. current meaning of blk_size array)
Date: Thu, 15 Nov 2001 13:31:33 -0500 [thread overview]
Message-ID: <20011115133133.A732@node0.opengeometry.ca> (raw)
In-Reply-To: <20011115003434.A25883@node0.opengeometry.ca> <200111151235.fAFCZQY31248@oboe.it.uc3m.es>
In-Reply-To: <200111151235.fAFCZQY31248@oboe.it.uc3m.es>; from ptb@it.uc3m.es on Thu, Nov 15, 2001 at 01:35:26PM +0100
On Thu, Nov 15, 2001 at 01:35:26PM +0100, Peter T. Breuer wrote:
> What is the forward strategy? I see no alternative but moving to 64bit
> sector counts.
Me too.
I looked around, and 1KB block size is hard-coded in too many places.
For example, function 'generic_make_request()' in
'drivers/block/ll_rw_blk.c' assumes 512 sector and 1024 block size:
if (blk_size[major])
minorsize = blk_size[major][MINOR(bh->b_rdev)];
if (minorsize) {
unsigned long maxsector = (minorsize << 1) + 1; <--
unsigned long sector = bh->b_rsector;
unsigned int count = bh->b_size >> 9;
So, using 'u64 *blk_size[][]' seems to be the most straightforward
solution, leaving BLOCK_SIZE alone.
I thought 'drivers/block/nbd.c' was already using 64-bit count,
according to its comment at the top. But, curiously, it reverts back to
'int' count of BLOCK_SIZE. I tried searching list archives for 64-bit
patch, but no luck.
Any URL would be helpful.
Is changing 'int' to 'u64' (and all the dependent code) enough to get
64-bit block devices? I'm willing to do the work. I don't care about
filesystem; that's the job for maintainer of particular filesystem. I
understand XFS is 64-bit, so I can use that.
--
William Park, Open Geometry Consulting, <opengeometry@yahoo.ca>.
8 CPU cluster, NAS, (Slackware) Linux, Python, LaTeX, Vim, Mutt, Tin
next prev parent reply other threads:[~2001-11-15 18:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-13 15:08 what is teh current meaning of blk_size? Peter T. Breuer
2001-11-13 18:51 ` blocks or KB? (was: .. current meaning of blk_size array) Peter T. Breuer
2001-11-14 9:44 ` Martin Dalecki
2001-11-14 20:41 ` Peter T. Breuer
2001-11-14 20:51 ` Martin Dalecki
2001-11-14 21:16 ` Andreas Dilger
2001-11-14 21:49 ` Benjamin LaHaise
2001-11-14 22:33 ` Scott Laird
2001-11-15 1:48 ` William Park
2001-11-15 4:58 ` Andreas Dilger
2001-11-15 5:34 ` William Park
2001-11-15 5:55 ` Andreas Dilger
2001-11-15 10:42 ` Anton Altaparmakov
2001-11-15 12:35 ` Peter T. Breuer
2001-11-15 18:31 ` William Park [this message]
2001-11-15 20:19 ` Andreas Dilger
2001-11-15 22:04 ` blocks or KB? William Park
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=20011115133133.A732@node0.opengeometry.ca \
--to=opengeometry@yahoo.ca \
--cc=adilger@turbolabs.com \
--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