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

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

tmcd@xxxxxxxx (Timothy A. McDaniel) writes:

> 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.

POSIX requires fsync. I'm not discussing about crap OS's. If Windows
does not have fsync or an equivalent, not my problem, not leafnode's
problem, if BeOS or MacOS does not have such, it's problem, for AmigaOS,
you can do equivalent and I believe the ixemul library that interfaces
AmigaOS to unistd.h and brothers and sisters implement a reasonable
fsync equivalent; always assuming the corresponding section has not been
written by Martin Tauchmann or other scapegraces.

You cannot expect a program to work correctly on a broken-by-design
system such as AmigaOS, TOS, Windows 9x or the like.

> 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.

If the program has shot itself in the foot, I'm not going to give it a
chance to shoot in its other foot as well. 

> 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.

No. The best is to make sure nothing bad happens regardless of state,
along with the inherent design that prevents any file corruption. 

Losing news for carelessness is not acceptable. 

> > 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.

You cannot reliably tell if writing control files actually worked out
the way it is supposed to be. Thus, the program must be designed so that
it only loses the transaction-in-progress and not its entire state. 

Re-fetching and discarding news duplicates is acceptable (especially not
if you do XHDR on the Message-Id before), while leafnode should
checkpoint every now and then.

-- 
Matthias Andree

                Where do you think you're going today?

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