On Fri, Jul 16, 2004 at 03:08:44PM -0500, Troy Benjegerdes wrote:
> > > 03:01:16 Reintegrate: u.hozer.mail, 100/1007 records, result = SUCCESS
> > > 03:01:18 fatal error -- fsobj::dir_Create:
> > > (1087644725.M331486P22611V0000000000000900I0011D52C_1.kalmia.hozed.org,S=2832,
> > > 6f558048.7f000005.cbf0.339d) Create failed!
> > > 03:01:23 RecovTerminate: dirty shutdown (1 uncommitted transactions)
> > > 
> > > Is there something I should look for in the server logs as to why this
> > > failed?
> > 
> > It looks like the maildir copy failed here. What is the size of the
> > directory you were copying?
> > 
> > Oh, and it definitely looks like your servers are unable to resolve
> > their differences, so their contents will slowly keep diverging until
> > everything is considered a conflict, or their respective resolution
> > logs are filled up.
> > 
> 
> Hrrm.. I bet the directory filled up.. what determines how many files a
> directory can have?
> 
> hozer_at_kalmia Maildir$ ls -ld .drgw/new
> drwx------    2 hozer    hozer      356352 Jul 16 14:42 .drgw/new
> hozer_at_kalmia Maildir$ ls .drgw/new/ | wc
>    4174    4174  320338
> 
> So.. the directory size (on ext3 is 356K), with 4174 files...

Ahh, there is a stupid limit, there are no double indirect blocks in the
RVM layout of Coda directories, so they can't exceed 256KB (roughly
about 4096 filenames in a maildir directory).

> So if I do a 'venus -reinit' and do a 'find /coda', will that force
> resolution of everything then?

venus -init or touch /usr/coda/venus.cache/INIT before starting venus.
I tend to use 'find /coda -noleaf', but that is to work around a GNU
find optimization that gets confused by volume mountpoints which are
really symlinks which don't increment the parent directory's link count,
but look like and should be treated as a directory.

Jan