Re: [leafnode-list] [ANNOUNCE:] leafnode-1.9.12

[tmcd@xxxxxxxx (Timothy A. McDaniel)]

Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote
> the software HAS to be designed in a way that it does not leave
> files in an inconsistent state that it cannot automatically and
> safely regenerate upon next start. Violating this standard is
> playing games with your data.  [an example of how to avoid it: write
> a new copy of the control file, flush, sync, atomically rename to
> the old name]

First, I agree (as stated before) that programs should not use buffers
that might overflow without it being detected and prevented before it
can happen.  Leafnode should use better code than a bigbuf solution,
and this discussion should therefore be moot.

(Which means you might want to go to the next message ...)

Also, I agree that a good program never leaves its control files (in
general, its permanent state) in a state that it can't fix.  (That is,
the files should never be inconsistent, or if they are, later runs of
the program should be able to roll back or roll forward.)  I agree
that we never know when a power failure will hit, for example, and not
many people have UPSes big enough to guarantee a safe shutdown.

Nevertheless, some OSes do not have good facilities for making sure
that I/O transactions have completed and written to disk.  There may
not *be* an fsync call, or atomic rename, or it may do nothing useful.

Furthermore, there are a lot of not-well-written programs out there.
In general, I try to give them a chance to die gracefully via "kill"
or "kill -HUP" and reserve "kill -9" as a last resort.

But that's in general and as an external user: we're talking about the
internals of a specific program when it thinks there's a buffer
overflow.  I think the best policy -- OK, the best is to make sure
neither overflow nor corruption happens -- the least-bad policy
depends on whether the permanent state is believed to be currently
corrupt or not.

> After an overflow, you don't know what you damaged. There is no way
> to recover, and it is harmful to even try ...

If the control file is believed to be in a state that's inconsistent,
unrecoverable as is, and transient at the moment (e.g., writing direct
to the control file, and the writing isn't done yet), there are two
choices:
- try to write the rest of the transaction, which may not work due to
  internal corruption, and may have other bad effects (wild writing to
  other files that may be open)
- die at once, which certainly WILL corrupt your control file.
Neither choice is good, but I'd be inclined to try to finish writing,
on the grounds that if you don't, you're CERTAINLY screwed.

-- 
Tim McDaniel is tmcd@xxxxxxxx; if that fail,
    tmcd@xxxxxxxxxx is my work account.
"To join the Clueless Club, send a followup to this message quoting everything
up to and including this sig!" -- Jukka.Korpela@xxxxxx (Jukka Korpela)

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list