lkml.org 
[lkml]   [2001]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: blocks or KB? (was: .. current meaning of blk_size array)
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
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.062 / U:5.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site