(Illustration by Gaich Muramatsu)
> 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 GribbleReceived on 1999-08-13 17:15:39