On Thu, Mar 28, 2002 at 09:19:20PM +0100, Lothar May wrote:
> 3. I set the cache size to 20000kb, drive h:.
...
> 7. I "drag-and-dropped" a directory on h: (size: 125 MB),
> which contained a file with a size of 60 MB. It took some time but it
> seemed to have worked.

I don't know much about the Windows XP client, but as a general rule
Coda is using a 'soft' cachesize limit when you are writing to a file.
Because the client won't see how big that file is until it is written,
it pushes it on towards the server and then throws it out of it's local
cache.

> 8. I tried to copy the directory back to the local hard disk. When
> trying to copy the file with the size of 60 MB, Windows said something
> like "Access fault while accessing memory area" and stopped the operation.
> I also couldn't delete the directory on the coda drive.

But when refetching the file we know what the size is going to be. So
here the client can be a lot stricter and it refuses to fetch the file.
This could be the cause of the access fault in WinXP's kernel.

> 10. I flushed the cache on the Windows client. I started an explorer
> to have a look at h:, and for some reason the coda client tried to send
> udp-packets to port 0 of the server, which were filtered by a
> firewall. After that Windows crashed badly.

Hmm, port 0, shouldn't happen but I think I've seen that before
somewhere. Nothing in my email folders, it will probably hit me when I'm
walking home tonight. The Windows crash is probably unrelated, except if
the port 0 braindamage led venus to not being able to return the
information of the root directory (i.e. what the kernel is supposed to
mount at h: )

Is this a cache flush or a venus/RVM reinit, is venus started from the
commandline, add a -init flag. Otherwise create an empty file 'INIT' in
the venus.cache directory and restart venus. That should wipe all the
state from RVM.

> Did I do something wrong? Or might the NT/2000/XP client have problems
> with large files?

No, any Coda client doesn't like files larger than the client cache. It
is a result of the combination of whole file caching, and for not
intercepting every single write call so that we can check what the
kernel/user application is doing with a file that is being written to.

> The same thing happened after I configured the cache size to 200000kb.

What, the store working, but the subsequent copy-back failing? Or the
packets to port 0 and the bad Windows crash? Venus doesn't use the
larger cache-size until RVM has been reinitialized.

> One other thing I noticed was that I can't see anything on the coda
> drive after I flushed the cache, even when I'm connected and there
> are files on the server. I get a strange error message like "got an eof
> signal".

Flushing the cache is typically pretty nasty, there is more chance of
something going wrong compared to simply reinitializing RVM from
scratch. The difference is that with a reinit we simple rebuild state
from nothing. While the cache-flush has to destroy state that might be
corrupt, objects could have references that keeps them from being
flushed, it might skip some objects if another thread is manipulating
the same list(s) as the flushing thread is walking etc. The cfs command
doesn't say 'fools rush in where angels fear to tread' for nothing.

Jan