From owner-cvs-all Mon Jun 24 2:39: 8 2002 Delivered-To: cvs-all@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id E9E7737B403; Mon, 24 Jun 2002 02:39:02 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 24 Jun 2002 08:38:35 +0100 (BST) To: Mike Silbersack Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, mckusick@mckusick.com 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: Your message of "Sun, 23 Jun 2002 21:54:50 CDT." <20020623215039.R49437-100000@patrocles.silby.com> Date: Mon, 24 Jun 2002 08:38:33 +0100 From: Ian Dowse Message-ID: <200206240838.aa78318@salmon.maths.tcd.ie> 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 In message <20020623215039.R49437-100000@patrocles.silby.com>, Mike Silbersack writes: >On Mon, 24 Jun 2002, Ian Dowse wrote: >> > Make vm_pindex_t 64-bit on all platforms. This is necessary to avoid >> > overflows with the large file sizes that UFS2 permits. >> >> Alan Cox pointed out that there are a few more VM changes necessary >> to fully support 64-bit file sizes as, for example, we are still >> using a 32-bit vm_size_t to store object sizes. I'll work with him >> and the other vm gurus to get these resolved. > >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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message