From owner-freebsd-current Wed Oct 6 14:52:25 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 10E231534E for ; Wed, 6 Oct 1999 14:52:14 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40324>; Thu, 7 Oct 1999 07:48:36 +1000 Content-return: prohibited Date: Thu, 7 Oct 1999 07:52:04 +1000 From: Peter Jeremy Subject: Re: make install trick In-reply-to: <199910060614.HAA24521@hak.lan.Awfulhak.org> To: Brian Somers Cc: freebsd-current@FreeBSD.ORG Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Oct7.074836est.40324@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <99Oct6.103524est.40351@border.alcanet.com.au> <199910060614.HAA24521@hak.lan.Awfulhak.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Oct-06 16:14:19 +1000, Brian Somers wrote: >> 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_. >[.....] > >:-] You're joking right ? Most applications don't even *notice* >the situation let alone handle it. I wasn't really joking. Applications _should_ handle this situation. Most coding standards tell you to check for error conditions. Most programmers (including myself most of the time) just don't bother. (One reason being that C suffers from extreme code bloat and substantial loss of readability. C++ exceptions are a definite improvement here). > Whaddaya do when /var/log runs >out of space ? Show me an app that handles it..... The only app that normally writes in /var/log is syslogd. And the behaviour you want in this case depends on the sysadmin's level of paranoia (anything from `ignore it' to `halt the system'). >I guess you can argue the case, but in real life, running out of any >machine resource can cause all sorts of possibly unrecoverable >problems. Agreed. One reason I (and presumably others) don't bother to check for some errors is that it's not clear what you can or should do if you get the error. > IMHO the best way to deal with it in a generic way is to >have the give-me-the-resource function block if it really thinks it's >a temporary thing. How do you work out whether the resource shortage is temporary or not? This situation is orthogonal to the ever-popular `out of swapspace' issue (normally brought up in conjunction with swap overcommit). The difficulty with any recovery strategy is avoiding deadlocks. (I suspect that a major reason why root is not constrained by UFS MINFREE was to try and avoid the situation where the _system_ (as against the users) ran out of disk space). >In the case of softupdtes, I'd be surprised if it couldn't easily >figure out that the problem is *probably* transient and block, To quote an excerpt from the response I got from Kirk when I asked him about this problem: : I experimented with keeping a count of space that was pending :removal. If the filesystem was about to return a space full message, :it would check the pending count for the filesystem and if there was :space that was going to show up in the future, it would request that :the space freeing be expedited then go to sleep and wait for it. The :problem is that the space freeing can take up to a minute (typically :more like 30 seconds) during which time the file's inode is :locked. If the locked file is say a log file, then you can get a :temporary lock race to the root which make for really terrible :perceived performance. If the inode is unlocked during the wait, then :file inconsistencies can sneak in. So, the short answer is that you :should not run soft updates on filesystems where you are running with :less than a 60 second reserve of free space. Note the last sentence... 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