On Fri, 30 Apr 2004, Jan Harkes wrote:
>     CLOSE file
> 	(OMG we exceeded the available cache space)
>
> At this point venus can't discard the file, because it is marked dirty.
> So it probably tries to throw as much as possible out of the cache and
> tries to write the file back to the server as soon as possible. Then it
> can throw the huge file out of the cache and from that point on will
> refuse to refetch it from the servers because it is to big.
Is there any chance Coda will ever (or soon?) have some kind of 'huge
file' mode where it would decide to not cache a file when its size is
above a certain limit but serve parts of it on request?

> > Then, more trouble: another client got write-disconnected from the server:
> >   Status of volume 0x7f000001 (2130706433) named "coda:home:jmartin"
> >   Volume type is ReadWrite
> >   Connection State is WriteDisconnected
> >   Minimum quota is 0, maximum quota is unlimited
> >   Current blocks used are 915870
> >   The partition has 34709316 blocks available out of 35737652
> >   Write-back is disabled
> >   There are 320 CML entries pending for reintegration
> > but cfs writereconnect doesn't seem to work, maybe because of
> >   16:36:50 volume coda:home:jmartin has unrepaired local subtree(s), skip checkpointing CML!
> >
> > I can't see any unrepaired subtrees, is there a way to find them?
>
> I typically use,
>
>     find /coda/path/to/volume -lname '@*'
Doesn't find anything, except for:
	jmartin_at_hatatitla:~$ find . -lname '@*'
	find: ./.DCOPserver_Halef_:0: No such file or directory
	find: ./.DCOPserver_Halef__0: No such file or directory
(actually, the first time I ran find I got a lot of timeouts in addition
to these messages, even though the client is on a very quiet network right
next to the server)

These are temporary KDE file (from some other machine) which show up fine
on the server. When I do an ls of the directory in question, they are
listed, ls -l reports a no such file or directory error, so does rm.

> Or you could look at the what the first entry of the CML checkpoint file
> is in,
>     /usr/coda/spool/<uid>/<volumename>.cml
>     (/var/lib/coda/spool on Debian)
That lists only files that aren't inconsistent or don't exist any more
(it's a few days old).

I guess
>> 16:36:50 volume coda:home:jmartin has unrepaired local subtree(s), skip checkpointing CML!
meant that this file isn't currently being updated?

Thanks
	Johannes