Date: Mon, 24 Jun 2002 10:23:22 -0700 From: Kirk McKusick <mckusick@beastie.mckusick.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: Mike Silbersack <silby@silby.com>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/powerpc/include types.h ... Message-ID: <200206241723.g5OHNMn9028383@beastie.mckusick.com> In-Reply-To: Your message of "Mon, 24 Jun 2002 08:38:33 BST." <200206240838.aa78318@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
To: Mike Silbersack <silby@silby.com>
cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org,
mckusick@mckusick.com
Subject: Re: cvs commit: src/sys/powerpc/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 <iedowse@maths.tcd.ie>
X-ASK-Info: Whitelist match
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
I would certainly like to lobby for bringing the VM system up to full
64-bit support. While it may seem like a long time before we will need
it, there is a distinct lag between the time that the work gets done
and the time that it gets deployed (often 3-4 years from initial
implementation to general use). Thus it behooves us to get this VM
work done now so that by the time it is needed, the users will have it.
Physical memories are large enough now that the additional overhead of
the larger data structures and code will just be lost in the noise.
Kirk McKusick
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206241723.g5OHNMn9028383>