> On Fri, Aug 13, 1999 at 02:37:16PM -0500, Bill Gribble wrote:
> > There's a process on the slow client creating log files (in a Coda
> > volume served by a third machine on the fast network) that are to be
> > analyzed by a process on the fast client.
> >
> > Everybody's clocks are synced by xntp.
> >
> > I ran my codes and found that the log files were never appearing on
> > the fast client (or, more precisely, appeared but were empty), even
> > though the slow client issued a 'cfs strong'.
>
> Hi Bill,
>
> Yup, that is a sometimes unexpected `feature' of the way Coda guarantees
> consistency of the filedata. As long as the (syslog?) daemon keeps the
> files open for writing, Coda assumes that the file is still in a state
> of inconsistency (being updated). The file will be sent as soon as the
> last writer closes it,. except if you are weakly connected, then it will
> take about 5 minutes longer. You can rotate the logs every once in a
> while to `flush' them to the servers.
Hmm... I understand how that might happen, but why is it that even now
(after I have read your reply, almost 2 hours after the last writer
process quit and "fuser" shows nobody having the file open for read or
write) the same thing is showing? i.e. full files on one client,
empty files on others, and specific 'cfs strong' directives to all
clients so everybody is strongly connected.
> Also you will not be able to easily `outsmart' the logic in venus by
> closing and opening the file between each write call. That stops working
> as soon as venus starts logging, then it uses the open-for-writing state
> of the file as an indication to optimize the pending stores out of the
> log.
I don't understand. If the file has been closed and that's not enough
to get it to sync, what other operation IS enough?
In any case, no one has opened these files for writing in hours and
they are inconsistent across clients. That seems broken to
me. Somehow venus has forgotten about these particular files. What
can I look for in the venus logs to show me what's going on?
> The best solution is to write the logs to local disk (/var/spool/...),
> and rotate them into /coda. Then your logger/application won't get stuck
> when the volume becomes read-only due to a conflict.
I'll try that in the future.
If it matters, the current sequence of events with approximate timings is:
Time/range Client Action
0s slow fopen("filename.log")
0+s-20s slow fprintf data
20+s slow fflush, fclose
20s-30s fast sleep, hoping for Coda to catch up
30+s-35s fast analyze data
35+s slow rename("filename.log", "filename.log.{n}")
(loop through this cycle indefinitely, incrementing {n}.)
Currently, on the first iteration of this loop, the data is available
for analysis on the fast client. On second and subsequent iterations,
(i.e. after a rename() call) new data never shows up on the fast
client.
Could it be the rename() call that's causing problems?
Thanks,
Bill Gribble
