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.
On Wed, Jul 19, 2000 at 10:44:28PM +0100, Dr A V Le Blanc wrote:
> I've just upgraded to coda 5.3.8 (lwp 1.4, rvm 1.1, rpc2 1.5)
> on a group of Linux 2.2.16 systems with libc 2.1.3, gcc 2.95.2.
...
> $ ll /tmp/wwwjob/Makefile
> -rw------- 1 zlsiial nogroup 518 Jul 19 07:42 /tmp/wwwjob/Makefile
> $ cp -p /tmp/wwwjob/Makefile .
> cp: ./Makefile: Invalid argument
> $ ll Makefile
> -rw------- 1 zlsiial nogroup 0 Jul 19 22:36 Makefile
> $ rm Makefile
> $ (cd /tmp/wwwjob;tar cf - Makefile)|tar xif -
> tar: Makefile: Cannot write
> tar: Error exit delayed from previous errors
On Thu, Jul 20, 2000 at 11:40:38AM -0400, Jan Harkes wrote:
> Now that is very strange. I am curious what is rejecting the operation.
> Does it only affect the Makefile file in that directory, or simply the
> creation of any file anywhere?
It seems to affect creation of any file anywhere.
> Does the kernel print any errors to the console (or use dmesg to see the
> last kernel error messages).
The last thing in dmesg is this:
coda_pioctl: Venus returns: -107 for (0x7f000000,0x1,0x1)
but I don't know if it happened when I tried to write a file.
> 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 )
connection::bandwidth avl.mcc.ac.uk 327225 351741 380228 ( 23:10:28 )
Remove passwd ( 23:10:29 )
connection::bandwidth avl.mcc.ac.uk 329055 356252 388349 ( 23:10:34 )
> 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
$
> Is the disk containing /usr/coda/venus.cache full?
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda2 3044060 713412 2330648 23% /
Coda 300000 304 106404 0% /coda
This is affecting all clients everywhere, so that was unlikely to be
the problem. Here's SrvLog from this period:
23:12:25 VN_PutDirHandle: Vn 1 Uniq 1: cnt 1, vn_cnt 1
23:12:25 VN_GetDirHandle for Vnode 0x1 Uniq 0x1 cnt 2, vn_cnt 2
23:12:25 VN_PutDirHandle: Vn 1 Uniq 1: cnt 1, vn_cnt 1
23:12:25 --DC: (0x80000019.0x1.0x1) ct: 1
23:12:25 VN_PutDirHandle: Vn 1 Uniq 1: cnt 0, vn_cnt 0
23:12:35 VN_GetDirHandle for Vnode 0x1 Uniq 0x1 cnt 1, vn_cnt 1
23:12:35 VN_GetDirHandle for Vnode 0x1 Uniq 0x1 cnt 2, vn_cnt 2
23:12:35 VN_PutDirHandle: Vn 1 Uniq 1: cnt 1, vn_cnt 1
23:12:35 VN_GetDirHandle for Vnode 0x1 Uniq 0x1 cnt 2, vn_cnt 2
23:12:35 VN_PutDirHandle: Vn 1 Uniq 1: cnt 1, vn_cnt 1
23:12:35 --DC: (0x80000019.0x1.0x1) ct: 1
23:12:35 VN_PutDirHandle: Vn 1 Uniq 1: cnt 0, vn_cnt 0
In the venus.log on the client, I'm getting thousands of these:
[ H(07) : 0005 : 23:10:13 ] binding::~binding: somebody forgot to decrement
before delete
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
[ D(02) : 0210 : 23:12:31 ] NotifyUserOfServerBandwidthEvent
[ D(02) : 0211 : 23:12:40 ] NotifyUserOfServerBandwidthEvent
[ D(02) : 0213 : 23:13:00 ] NotifyUserOfServerBandwidthEvent
[ T(01) : 0217 : 23:13:40 ] BeginRvmFlush (1, 53636, I)
[ T(01) : 0217 : 23:13:40 ] EndRvmFlush
[ T(01) : 0218 : 23:13:50 ] BeginRvmTruncate (28, 53796, I)
in the middle of the above entries. (The venus.log has 8232 lines,
of which 8024 are the above message about forgetting to decrement;
this is after about 15 minutes uptime.)
-- Owen
[EMAIL PROTECTED]
