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) [EMAIL PROTECTED]
Alcatel Australia Limited
41 Mandible St Phone: +61 2 9690 5019
ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
