Re: 32/64 bit b_rsector type

[David Chow <davidchow@shaolinmicro.com>]

I think page cache will probably limited by the hashing functions which
is type sensitive to page->index.

Dave Kleikamp 提到:

>On Wed, 2004-03-24 at 11:06, Bryan Henderson wrote:
>  
>
>>Why would we have to stop?  Doesn't this just mean access through the page 
>>cache would remain limited to 16TB?  What if I don't really care about 
>>access to the device with read() -- I just want to put a filesystem on it? 
>> Would the simple change the bh->b_rsector enable that?
>>    
>>
For me, I would like to just to put a specialized LVM or 64-bit nbd
server on it.

>mkfs and fsck may have an issue with the inability to do reads and
>writes to the device.
>
For my issue (which I originally brought up) is not targeted to use with
fsck or mkfs . I am researching to build a cluster IP-based storage
infrastructure with special interconnects. We will use software-based
RAID drivers which I can't see direct benefits from using 64-bit
machines. For cost reasons, I would really want to stick with 32-bit
machines wiht high speed CPUs but with the ability to access blocks
beyond 16TB.

Large pages is not my direction, because pages will be send/receive from
multiple IP NIC's which is not a good idea to break things up nor to
send large chunks.

For page cache or buffer cache or any cache, page->index and
bh->b_rsector will definitely have to change to u64 to fullfil the
requirement. And of course, fsck and mkfs will break if this is true, fs
drivers will also have to be patched and checked for type corrections.
Still, I would like to hear more voices from experienced fs developers
(like you guys) to explore potential issues before I actually modify the
code.

Thanks for pointing out. ^_^

regards,
David Chow

>  
>

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