From owner-cvs-all Mon Jun 24 10: 5:21 2002 Delivered-To: cvs-all@freebsd.org Received: from patrocles.silby.com (d91.as7.nwbl0.wi.voyager.net [169.207.128.219]) by hub.freebsd.org (Postfix) with ESMTP id 1F22F37B400; Mon, 24 Jun 2002 10:05:14 -0700 (PDT) Received: from patrocles.silby.com (localhost [127.0.0.1]) by patrocles.silby.com (8.12.4/8.12.4) with ESMTP id g5OH7Scv053391; Mon, 24 Jun 2002 12:07:28 -0500 (CDT) (envelope-from silby@silby.com) Received: from localhost (silby@localhost) by patrocles.silby.com (8.12.4/8.12.4/Submit) with ESMTP id g5OH7Qi2053388; Mon, 24 Jun 2002 12:07:27 -0500 (CDT) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 24 Jun 2002 12:07:26 -0500 (CDT) From: Mike Silbersack To: Ian Dowse Cc: cvs-committers@FreeBSD.org, , Subject: Re: cvs commit: src/sys/powerpc/include types.h src/sys/arm/include types.h src/sys/i386/include types.h In-Reply-To: <200206240838.aa78318@salmon.maths.tcd.ie> Message-ID: <20020624120420.A53369-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Jun 2002, Ian Dowse wrote: > In message <20020623215039.R49437-100000@patrocles.silby.com>, Mike Silbersack > writes: > >Do we need to bother supporting such large files in the kernel yet? 8TB > >(if I'm understanding this correctly) is VERY large, and won't be bumped > >into for a few years. I'm all for changing filesystem structures (which > >can't be tweaked on the fly the day a 7TB file grows to 8TB in size), but > >I don't see an urgent need to modify the kernel yet. > > It's a good question. One of the goals of the UFS2 work seems to > have been to make the filesystem fully 64-bit clean. The size of > ufs_lbn_t was increased to 64-bit and all kernel-imposed file size > limits were removed. The ufs_lbn_t type does not appear in any > on-disk structures, so it's only effect is to allow the kernel to > access very large files. I'm just trying to extend that the final > step so that we can really use >8TB files. If we decide not to do > this we need to re-introduce the file size limits and ufs_lbn_t can > go back to 32-bit again. > > There are some good arguments for allowing >8TB files though. The > first is that snapshots are filesystem-sized files, so limiting > files to 8TB would limit filesystems to 8TB (I think this is true). > It would be unfortunate if all of the UFS2 work only gave us a > factor of 8 instead of 8,000,000 increase in maximum filesystem > size. The second reason is that we can test the creation of large > filesystems within large sparse files. > > Ian Ah, you raise some very good points. I was not aware that snapshots are sized equal to the partition, nor had I considered sparse files. Would it be feasible to have different limits for 64-bit and 32-bit systems? Also, would it be possible to #ifdef the 64-bit code for i386 so that only people using such large filesystems would be impacted by the speed hit? Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message