Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g0TLhfr28042 for linux-xfs-outgoing; Tue, 29 Jan 2002 13:43:41 -0800 Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g0TLhXd28020 for ; Tue, 29 Jan 2002 13:43:33 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA13787 for ; Tue, 29 Jan 2002 21:41:44 +0100 (CET) mail_from (sandeen@sgi.com) Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA204975; Tue, 29 Jan 2002 14:42:12 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA91098; Tue, 29 Jan 2002 14:42:12 -0600 (CST) Subject: Re: [PATCH] Re: Reduce XFS footprint (was Re: TAKE - remove a function xfs added to filemap.c From: Eric Sandeen To: Andi Kleen Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20020129211758.A8117@wotan.suse.de> References: <200201291751.g0THp897004750@scare.vieo.com> <20020129194001.A16401@wotan.suse.de> <20020129202509.A31370@wotan.suse.de> <1012334201.5905.25.camel@stout.americas.sgi.com> <20020129211758.A8117@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 29 Jan 2002 14:42:12 -0600 Message-Id: <1012336932.30169.36.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Status: O Content-Length: 1837 Lines: 58 On Tue, 2002-01-29 at 14:17, Andi Kleen wrote: > On Tue, Jan 29, 2002 at 01:56:41PM -0600, Eric Sandeen wrote: > > Yep, I just saw that. And FWIW, the stated limit for the filesystem > > size w/o XFS_BIG_FILESYSTEMS isn't quite right*. I think these are > > correct (these are internal XFS limitations): > > > > File size: > > o Without XFS_BIG_FILES, the max filesize is 1<<40, or 2TiB. > > I misread blockno in xfs_types.h as byteno. It should be 2^31 * blocksize, > which would be 2^43 with 4K blocks or more with bigger block size. > I don't see any other limit. > > How do you get to 2^40 ? in xfs_inode.h: #if XFS_BIG_FILES #define XFS_MAX_FILE_OFFSET ((long long)((1ULL<<(32+PAGE_SHIFT))-1ULL)) #else #define XFS_MAX_FILE_OFFSET ((1LL<<40)-1LL) #endif and XFS_MAX_FILE_OFFSET is used to set sb->s_maxbytes (the latter case is stock XFS, the former is something I changed, might be off by a factor of 2? hm....) The comment blurb says * if XFS_BIG_FILES [...] * else 2^40 - 1 (40=31+9) (might be an int holding a block #) Not quite sure where this comes from, actually. > Also Linux/32bit is VM limited to 2^31 * PAGE_SIZE, so assuming PAGE_SIZE== > blocksize XFS_BIG_FILES should not be needed at all on 32bit linux. Does the VM actually enforce this limit? I thought I had a case where I could create a too-large file if XFS allowed it. Also I thought the limit was 2^32 * PAGE_SIZE... /me goes back to look. > On 64bit it probably makes sense to hardcode them both to 1. > > Where I am wrong ? > > > o With XFS_BIG_FILES, the max filesize is 1<<63-1. > > However, Linux can only handle 1<<(32+PAGE_SHIFT), or > > 2^(31+PAGE_SHIFT) Whoops... so the page cache index is signed...? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc.