[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PROPOSAL] Return of the (svnserve) log

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2005-10-31 12:10:02 CET

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.


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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.