[Dovecot] testing needed: log file concurrency

[Adam McDougall]

If there is no output, whats the longest you want us to wait
while it runs?  How much do you care about unique OS/arch/cpu/fs
combinations (what factors shouldn't matter)?  I assume you want
just one reader and one writer, started in the order listed in
the source?

I currently have it running on SMP(quad) FreeBSD 6.2-STABLE amd64 Sat Jun 16 2007 
on both ufs2 and nfs to our NetApp, and UP FreeBSD 6.2-STABLE i386 Tue Jan 16 2007
on ufs2, maybe some more systems after I send this mail, and a little later I can
try it on UP FreeBSD 7 with zfs.  The ones I already have running for a few
minutes have printed nothing so far.  

On Wed, Jun 20, 2007 at 02:41:42AM +0300, Timo Sirainen wrote:

  http://dovecot.org/tmp/concurrency.c
  
  I'd want to know what results this program gives with different systems.
  Please test and reply (but don't bother if someone already replied with
  the same OS+result). I expect it to print:
  
   - SMP kernels: "page size cut" once in a while
   - UP (uniprocessor) kernels: Nothing
   - The most important thing is that it never prints "broken data"
  
  It might take a while for it to print anything. With my computer it
  takes anything from a few seconds to a minute or so. See the file itself
  for compiling/running instructions.
  
  So far I've tested only with Linux 2.6.21 x86-64/SMP and a slow
  Solaris/Sparc/UP.
  
  If you're interested in knowing what this is about:
  
  Dovecot writes to dovecot.index.log files by first writing the
  transaction with its size being 0. After that it writes the 4 size bytes
  again (using a bit special format with all bytes ORed with 0x80).
  
  I expected that when another process is read()ing the file and it
  notices the size being valid (all bytes having 0x80) that the whole
  transaction could always be read. But looks like if the size happens to
  be just before a memory page boundary, it's possible that the updated
  size is read, but the rest of the transaction isn't.