svn commit: samba r13770 - in branches/SAMBA_4_0/source/lib/util: .

tridge at samba.org tridge at samba.org
Mon Mar 6 12:13:22 GMT 2006


Metze,

 > > Shrink the default size of the buffer: if it happens
 > > to be stdio down under there, setvbuf it.
 > 
 > is there something like this for filedescriptors?

It isn't needed for file descriptors. setvbuf() and related calls are
ways of controlling the user space buffering in the libc stdio
library. In the Samba4 debug code we are writing directly to a file
descriptor, which is like running stdio with no buffering at all.

It is a common misconception that flush() and fsync() are the same
thing, but they are in fact completely different. A flush() call tells
the libc stdio buffer to be written to the operating system (via a
write() call). A fsync() call tells the kernel to ensure that stuff
written to file descriptors has been placed on stable storage (ie. on
the metal of the disk).

We should not be calling fsync() anywhere in our debug code. The only
time it could possibly help is if the power were to fail to the
server, but preserving log files in that case is just not worth the
massive slowdown of calling fsync(). When you write with fsync() you
go hundreds of times slower.

 > I have also the idea we could count the bytes we write to the debug file,
 > and then do a fsync after writing 8 KByte or so...

no, we should not call fsync() at all in our debug code.

 > I'm also unsure how we handle the case, then an admin
 > removes the log file, we may need to reopen the log file in this case...

we should catch a SIGHUP and re-open the logs.

Cheers, Tridge


More information about the samba-technical mailing list