[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: Jonathan Gilbert <o2w9gs702_at_sneakemail.com>
Date: 2005-10-30 19:45:20 CET

At 10:48 AM 30/10/2005 -0500, Greg Hudson wrote:
>At any rate, standard practice for logfiles is to open them in append
>mode and write out each log message in a single write(), which is
>guaranteed to be atomic. If we do that, then multiple handles to the
>same file due to symlinks should be a resource-consumption issue only,
>not a correctness issue.

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. The only way I can see to be *absolutely sure* is to use an OS-level
synchronization function. Since cross-process synchronization is likely
more expensive that in-process synchronization, perhaps this should be
selected at startup based on the user's choice of connection mode (threads
vs. fork).

If I'm wrong, does anyone have an authoritative source of information that
guarantees that write() will either write all of its data or none?

Another minor issue is that the Linux man page for write() (section 2)
indicates that there exist filesystems where write() doesn't even guarantee
that space on the device has been reserved for the device, let alone that
the data has been written. If the two file handles don't know about each
other, then we also need to fsync() after every write(), and this creates a
race condition in the absence of synchronization.

Jonathan Gilbert

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 30 20:09:23 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.