On Mon, Jul 24, 2000 at 11:24:18AM +0100, Dr A V Le Blanc wrote:
> I've still received no advice about this; did it get through
> to the list?  I can still not write any files in coda, though
> I can delete files and create or delete directories.

Well, it's just that I'm puzzled.

On Wed, Jul 19, 2000 at 10:44:28PM +0100, Dr A V Le Blanc wrote:
> On Thu, Jul 20, 2000 at 11:40:38AM -0400, Jan Harkes wrote:
> > Is any activity in codacon indicating that venus tries to send a
> > Create/Store to the server.
> 
> Here is 'cp /etc/passwd .;rm passwd':
> 
>      Create passwd ( 23:10:23 )
>      Store passwd [0] ( 23:10:23 )

This indicates that when Venus receives the close upcall, the container-
file is zero length. I'll have to look whether some changes were made in
2.2.16 that are causing this.

> > It looks like the create succeeds, but the store operation is completely
> > failing. On what operation does it return EINVAL,
> >  `strace -e trace=file cp -p /tmp/wwwjob/Makefile' should show that.
> 
>      $ strace -e trace=file cp -p /etc/passwd .
>      execve("/bin/cp", ["cp", "-p", "/etc/passwd", "."], [/* 20 vars */]) = 0
>      open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
>      open("/etc/ld.so.cache", O_RDONLY)      = 3
>      open("/lib/libc.so.6", O_RDONLY)        = 3
>      lstat(".", {st_mode=S_IFDIR|0711, st_size=2048, ...}) = 0
>      stat(".", {st_mode=S_IFDIR|0711, st_size=2048, ...}) = 0
>      stat("/etc/passwd", {st_mode=S_IFREG|0644, st_size=1104, ...}) = 0
>      stat("./passwd", 0xbffff7dc)            = -1 ENOENT (No such file or directory)
>      open("/etc/passwd", O_RDONLY|0x8000)    = 3
>      open("./passwd", O_WRONLY|O_CREAT|O_TRUNC|0x8000, 0600) = 4
>      utime("./passwd", [2000/07/20-23:10:23, 2000/07/19-00:01:34]) = 0
>      chown("./passwd", 102, 0)               = 0
>      chmod("./passwd", 0100644)              = 0
>      $

Didn't see any of the read/write/close calls here, I figured that the
open() or close() calls would be failing, but from this trace it looks
like nothing is wrong.

>      [ H(07) : 0005 : 23:10:13 ] binding::~binding:  somebody forgot to decrement before delete

These are always there around disconnections, they indicate that some
reference counting went wrong, but they are reasonably harmless.

> and I guess these are from about the time of the problem:
> 
>      [ D(02) : 0197 : 23:10:34 ] NotifyUserOfServerBandwidthEvent
>      [ D(02) : 0199 : 23:10:49 ] NotifyUserOfServerBandwidthEvent
>      [ T(01) : 0203 : 23:11:29 ] BeginRvmTruncate (173, 4116, I)
>      [ T(01) : 0203 : 23:11:30 ] cache::EndRvmTruncate
>      [ W(20) : 0000 : 23:12:25 ] Cachefile::SetLength 0

Yes, after the close, venus stat(2)'s the containerfile and at that time
it has a size of 0 bytes.

I'll install a 2.2.16 kernel today to see if I can reproduce the problem.

Jan