On 12/5/06, Joe Advisor <[EMAIL PROTECTED]> wrote: ...
If this is the case, does this mean that I am in an either / or situation... as in, it is not possible to have rapid rewrites and rapid reboot simultaneously.
The problem is related to the process of repeatedly growing the file and then truncating it. If you didn't truncate the file completely but instead overwrote the beginning (possibly finishing with an ftruncate() to set the final size) then the effects would be greatly diminished. If the data is fixed size, so that no truncation is necessary at all, then the problem would go away completely. For example, try this from ksh: i=0; while true; do echo "foo$((i++))" 1<> /foo; done The <> syntax keeps the shell from truncating the file (the '1' does that on stdout instead of <>'s default of stdin). I added the $((i++)) so that you can see that the file contents are actually changing. I see [EMAIL PROTECTED] makes this point too. He mentions fsync(), but you only need that if you need to guarantee that any operations *after* the fsync() will only be visible if all the operations on the fd *before* the fsync() are persistent, even in the face of an OS crash. It's a kind of brute-force barrier on the reordering of operations... Philip Guenther
