Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 30 Nov 2001 06:32:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 30 Nov 2001 06:32:16 -0500 Received: from dsl-213-023-038-163.arcor-ip.net ([213.23.38.163]:13583 "EHLO starship.berlin") by vger.kernel.org with ESMTP id ; Fri, 30 Nov 2001 06:32:04 -0500 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Linus Torvalds , Jeff Garzik Subject: Re: Block I/O Enchancements, 2.5.1-pre2 Date: Fri, 30 Nov 2001 03:19:09 +0100 X-Mailer: KMail [version 1.3.2] Cc: Jens Axboe , , In-Reply-To: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On November 28, 2001 04:38 am, Linus Torvalds wrote: > We will probably _not_ get 64-bit page index numbers, though. I don't want > to make the page structure bigger/slower for very little gain. So the page > cache is probably going to be limited to about 44 bits (45+ if people > start doing large pages, which is probably worth it). So there would still > be partition/file limits on the order of 16-64 TB in the next few years. The Ext2+ crowd is actively working on preparing for the world of larger blocks, so that 64KB blocks will be entirely practical. This will get us to 1/4 Petabyte, still with 32 bit block pointers internally. The main problem that has to be solved is internal fragmentation. Going beyond 64KB blocks with mimimal changes is possible too, basically just working around the 16 bit pointers in directory blocks. However, it's not clear it's a pressing need. > (In a longer timeframe, assuming RAM keeps getting cheaper and cheaper, > and 64-bit computing starts hppening on PC's, a few years down the line we > can re-visit this - that particular transition is not going to be too > painful). > > And yes, I realize that you can already build big arrays and use LVM etc > to make them be more than 16TB. I just do not think it's a problem yet, > and I'd rather cater to "normal" people than to peopel who can't bother > to partition their data at all. Right, there's still a lot more scalability to be squeezed out of good old 32 bits. If we do run out of something it's likely to be the 32 bits of inodes, after all, who can get by on a mere 4 billion files these days? -- Daniel - 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/