> > So, I think we are safe if we can either keep that file descriptor open
> > until commit, or re-open it and fsync it on commit. That assume a
> > re-open is hitting the same file. My opinion is that we should just
> > fsync it on close and not worry about a reopen.
>
> I'm pretty sure that the standard is that a close on a file _should_
> fsync it.
This is not true. close flushes the user buffers to kernel buffers. It
does not force to physical disk in all cases, I think. There is really
no need to force them to disk on close. The only time they have to be
forced to disk is when the system shuts down, or on an fsync call.
>
> In re the fsync problems...
>
> I came across this option when investigating implementing range fsync()
> for FreeBSD, 'O_FSYNC'/'O_SYNC'.
>
> Why not keep 2 file descritors open for each datafile, one opened
> with O_FSYNC (exists but not documented in FreeBSD) and one normal?
> This garantees sync writes for all write operations on that fd.
We actually don't want this. We like to just fsync the file descriptor
and retroactively fsync all our writes. fsync allows us to decouple the
write and the fsync, which is what we really are attempting to do. Our
current behavour is to do write/fsync together, which is wasteful.
-- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026