All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.