(Illustration by Gaich Muramatsu)
> cfs wbauto /coda/marvin is going to hang, if I control+C it, the > following is issued to dmesg: The 'writeback' code isn't really useful, the idea was nice but it never really worked out the way we hoped it would. The basic idea was that we wanted to have client work write-disconnected all the time, but have 'connected' mode semantics. This was achieved by having client obtain a writeback permit as soon as they had CML entries for a volume. The server would also preemptively break callbacks to all other clients. Now if another client ended up being interested in a file in the volume, the server would break the writeback permit and force a reintegration before responding to the getattr or fetch. The problem was that as a result of the callback, other clients would often fairly quickly refetch the attributes due to a hoard walk or an ls in a directory that contained the mountpoints of all user volumes. So a write-disconnected client had to constantly reintegrate even if they didn't have any relevant updates, and if they were connected over a slow connection they would stall all other clients until the reintegration completed. Any case, I've decided to take most of the writeback related code out. > coda_pioctl: Venus returns: -4 for (0x7f000000.0x1.0x1) EINTR (i.e. ^C) > coda_pioctl: Venus returns: -22 for (0x7f000000.0x1.0x1) EINVAL > Is there a list with all errorcodes? How can I get this client back into > 'normal' mode, what can I do to prevent these problems? What could be the > cause? Most of the errorcodes really are the standard unix errornumbers. I typically do a 'grep 22 /usr/include/asm/errno.h', except that on recent glibc systems they've moved and split the errno.h file into /usr/include/asm-generic/errno-base.h and /usr/include/asm-generic/errno.h. Then there are a couple of error numbers that are Coda specific. I believe 198 is EINCONS /* inconsistent file */, 103 is VNOVOL /* volume not found */ and a bunch of others. The problem with some error codes like VNOVOL is that they also have an existing errno.h definition, in this case it is ECONNABORTED, which can be a bit confusing sometimes. In any case, I don't know why it isn't (yet) reintegrating. There are some tests that check if the owner of the CML has valid tokens. Sometimes a setuid application actually writes to files with a different uid than you'd expect so you would need to get tokens for f.i. root or some other local user. JanReceived on 2004-04-30 13:37:16