From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Chow Subject: Re: 32/64 bit b_rsector type Date: Fri, 26 Mar 2004 00:43:39 +0800 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <40630C3B.205@shaolinmicro.com> References: <1080148394.29046.97.camel@shaggy.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Bryan Henderson , Matthew Wilcox , fsdevel Return-path: Received: from [202.131.75.34] ([202.131.75.34]:57243 "EHLO staff.shaolinmicro.com") by vger.kernel.org with ESMTP id S263364AbUCYQlx (ORCPT ); Thu, 25 Mar 2004 11:41:53 -0500 To: Dave Kleikamp In-Reply-To: <1080148394.29046.97.camel@shaggy.austin.ibm.com> List-Id: linux-fsdevel.vger.kernel.org I think page cache will probably limited by the hashing functions which is type sensitive to page->index. Dave Kleikamp =B4=A3=A8=EC: >On Wed, 2004-03-24 at 11:06, Bryan Henderson wrote: > =20 > >>Why would we have to stop? Doesn't this just mean access through the= page=20 >>cache would remain limited to 16TB? What if I don't really care abou= t=20 >>access to the device with read() -- I just want to put a filesystem o= n it?=20 >> Would the simple change the bh->b_rsector enable that? >> =20 >> =46or 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. > =46or my issue (which I originally brought up) is not targeted to use w= ith 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 fro= m multiple IP NIC's which is not a good idea to break things up nor to send large chunks. =46or 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, f= s 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 th= e code. Thanks for pointing out. ^_^ regards, David Chow > =20 > - 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