From owner-freebsd-current Tue Oct 5 17:39:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 5284414D41 for ; Tue, 5 Oct 1999 17:39:02 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40351>; Wed, 6 Oct 1999 10:35:24 +1000 Content-return: prohibited Date: Wed, 6 Oct 1999 10:38:49 +1000 From: Peter Jeremy Subject: Re: make install trick In-reply-to: To: Alfred Perlstein Cc: freebsd-current@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct6.103524est.40351@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <000101bf0f78$fbe58b40$021d85d1@youwant.to> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-06 09:55:26 +1000, Alfred Perlstein wrote: >I've seen softupdates nearly eliminate disk io for systems that used >an abmornal amount of temp files, but the fact that it can destabilize >a system worries me greatly. What do you mean by `destabilize'? There are bugs in softupdates which mean that an application may receive ENOSPC when writing to a filesystem even though space on that filesystem has been recently freed. Any application that cannot handle this situation is _broken_. Another option for /tmp - which I forgot last time, and seems to avoid the known problems with MFS and softupdates - it to mount /tmp async. Since you're going to blow it all away on the next reboot anyway, it doesn't really matter if the a crash trashes the FS (which is the major problem with async mounts). Peter -- Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message