Date: Thu, 7 Oct 1999 07:52:04 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Brian Somers <brian@Awfulhak.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: make install trick Message-ID: <99Oct7.074836est.40324@border.alcanet.com.au> In-Reply-To: <199910060614.HAA24521@hak.lan.Awfulhak.org> References: <99Oct6.103524est.40351@border.alcanet.com.au> <199910060614.HAA24521@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Oct7.074836est.40324>