Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262122AbVCIWG3 (ORCPT ); Wed, 9 Mar 2005 17:06:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262071AbVCIWGD (ORCPT ); Wed, 9 Mar 2005 17:06:03 -0500 Received: from rev.193.226.232.162.euroweb.hu ([193.226.232.162]:22935 "EHLO dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP id S261927AbVCIWCY (ORCPT ); Wed, 9 Mar 2005 17:02:24 -0500 To: strombrg@dcs.nac.uci.edu CC: linux-kernel@vger.kernel.org In-reply-to: (message from Dan Stromberg on Wed, 09 Mar 2005 10:53:48 -0800) Subject: Re: huge filesystems References: Message-Id: From: Miklos Szeredi Date: Wed, 09 Mar 2005 23:01:58 +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1161 Lines: 29 > The group I work in has been experimenting with GFS and Lustre, and I did > some NBD/ENBD experimentation on my own, described at > http://dcs.nac.uci.edu/~strombrg/nbd.html > > My question is, what is the current status of huge filesystems - IE, > filesystems that exceed 2 terabytes, and hopefully also exceeding 16 > terabytes? > > Am I correct in assuming that the usual linux buffer cache only goes to 16 > terabytes? The page cache limit is PAGE_CACHE_BITS + BITS_PER_LONG - 1. On i386 that's 12 + 32 - 1 = 43 bits or 8Tbytes. On 64 bit architectures the size of off_t is the only limit. > Does the FUSE API (or similar) happen to allow surpassing either the 2T or > 16T limits? The API certainly doesn't have any limits. The page cache limit holds for FUSE too, though with the direct-io mount option the page cache is not used, so the limit could be removed as well. I'll fix that. Thanks, Miklos - 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/