Date: Wed, 07 Jun 2000 00:42:32 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, "mouss" <usebsd@free.fr>, "Peter van Dijk" <petervd@vuurwerk.nl>, freebsd-security@FreeBSD.ORG Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Message-ID: <200006070742.e577gfm04277@cwsys.cwsent.com> In-Reply-To: Your message of "Tue, 06 Jun 2000 23:55:03 PDT." <200006070655.XAA97086@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200006070655.XAA97086@apollo.backplane.com>, Matthew Dillon writes: > :> also, the BSD/OS mfs proposal is not that god. This limits the size of /tm > p, > :> and uses mfs for things that do not need to be in mfs. > :> the first thing I used to do on BSD/OS was to remove the mfs mount and to > :> softlink /var/tmp to /tmp. > : > :I disagree with this. /tmp is cleared at boot while /var/tmp is not. > :The reason for this is to have files remain across boot. > :mfs is generally (arguably on some O/S's) faster than writing data to > :disk. (If writing to disk is faster than using mfs, assuming there's > > MFS is a terrible idea for /tmp. Each page in an MFS filesystem eats > *TWO* pages of physical memory (until swapped). This means that the > active dataset (what processes have accessed recently) eats twice > as much physical memory as it needs to. MFS also needlessly loads > down the VM system when it does start to stress memory. Simple > things like someone tar xvf'ing a large distribution in /tmp can bring > the machine to its knees with an MFS partition where the same operation > on a normal filesystem would barely glitch most of the resource meters. > > MFS would be my *LAST* choice for a tmp. Is this because one page is in the cache and the other is in MFS? I can see that would be a problem. > > Like it or not, /tmp and /var/tmp are here to stay. /usr/tmp doesn't > exist on most systems (thank god!), so it would be stupid of us to add > it in. I didn't say that I wanted /usr/tmp! /usr/tmp is an ancient idea that was replaced by /var/tmp in the last ice age. Why would we want /usr/tmp? If we're going to do that let's have a /usr/spool and /usr/adm. /tmp and /var/tmp doesn't hold much water either. Most applications support the use of TMP and TMPDIR environment variables. Applications that don't support a TMP environment variable should be changed. /tmp and /var/tmp is a concept that is past its prime and should be retired lieu of a more secure paradigm. Anything less than this must be considered unacceptable in a secure operating system. So far no one has convinced me that /tmp and/or /var/tmp cannot be phased out. I have not seen any good arguments to keep them over the long term. Don't forget, applications can be changed to use the new paradigm. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006070742.e577gfm04277>