On Mon, Oct 31, 2005 at 01:49:25AM -0500, Greg Hudson wrote:
> > I don't see how this can guarantee what we need. While whatever a write()
> > sends out is guaranteed to be atomic, the write() function is capable of
> > doing partial writes, and there's no way to be certain that it won't do
> > that.
>
> I believe that for regular files on a local filesystem, write() does all
> or nothing. I don't have an authoritative source, since I didn't manage
> to pull up either the SUS or POSIX standards on the web easily.
>
http://www.opengroup.org/onlinepubs/009695399/
In general, it's implementation-defined for regular files (FIFOs and
pipes have their own rules, of course). Some implementations make
certain small writes atomic, for example.
But for log files, atomic writes _are_ pretty-much guaranteed in
practice, by:
"If the O_APPEND flag of the file status flags is set, the file offset
shall be set to the end of the file prior to each write and no intervening
file modification operation shall occur between changing the file offset
and the write operation."
Or, in other words, if you're appending to a file, you'll always end
up writing to the end of the file, even if you're racing with another
write(). This assumes that libc or equivalent implements write()
by calling the underlying syscall only once, of course, but that's
generally true.
I think signals and resource limits are a red herring: we don't see
non-fatal signals in svnserve with any frequency, and resource limits
will hit every process anyway.
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 31 12:11:01 2005