Date: Thu, 26 Oct 1995 06:56:19 -0700 (PDT) From: John Dyson <dyson> To: terry@lambert.org (Terry Lambert) Cc: terry@lambert.org, bde@zeta.org.au, CVS-commiters@freefall.freebsd.org, bde@freefall.freebsd.org, cvs-sys@freefall.freebsd.org, hackers@freebsd.org, swallace@ece.uci.edu Subject: Re: SYSCALL IDEAS [Was: cvs commit: src/sys/kern sysv_msg.c sysv_sem.c sysv_shm.c] Message-ID: <199510261356.GAA06844@freefall.freebsd.org> In-Reply-To: <199510252135.OAA19692@phaeton.artisoft.com> from "Terry Lambert" at Oct 25, 95 02:35:47 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 2^12 * 2^31 = 2^43. > 2^43 << 2^63. > > The problem is for large file systems, and a lesser problem, large files > on large file systems (lesser because a file will always be smaller > than the FS that contains it). > > Right now it is impossible to support those files for which quad is > a desirable type for off_t because of VM limitations imposed. The > imposition is present codified in ffs_vmlimits() in the source file > /sys/ufs/ffs/ffs_vfsops.c. > The VM limitations are due to extreme performance hits if we have to go to a (long long) type representation of a page. I propose that we (in fact we will) move from page offsets to page indexes. For a 32 bit machine, it gives us at least 8TB (and probably more with sign extension fixes) for file/filesystem sizes. For a 64 bit machine it would give us even more (by a factor of 4,000,000). As far as the API is concerned, we can use whatever we want -- long, long long, or whatever. We will just have that terrible, limiting capability of supporting only 8TB files on 32 bit machines with 4K pagesizes. We haven't worked on the sign extension problems, because simply we do not support files > 4GB (or is it 2GB???) period right now. I don't believe that there is a problem with block devices (we do NOT use vmio for those.) But additionally we do not support mmaping them right now. > > The codification in ffs_vmlimits() is an interface violation in any > case: it is a machine architecture dependency, and in acutality a > vmio dependency and doesn't belong in the supposedly machine independent > FS code anyway. > I agree - but it made it work for now. The changes have been so vast that there has been significant ugliness added to the code. That is being worked on, and I suggest that if there are some architectural problems that you see -- 'corrected' code would be helpful. Note also some sort of performance analysis and architectural impact review is desirable. All I can say is that I spent nearly a year working on the most horrible OS code that I ever saw -- SVR4, and I don't want us to go down the low performance path that they did. They got both the hackery and low performance. At least we are working on cleaning up the hackery aspects, including that which was inherited from Mach (because of the differences in the philosophy -- Mach VM and the original BSD port was certainly interesting.) John dyson@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510261356.GAA06844>