well, actually I use wireless some of the time, both near the server
and across the 28.8 link.  But recently I've been on wired Ethernet
since I had some grief with the internal wireless on the Thinkpad T30
(interoperting with 802.11 (not b) stuff in IBSS mode, and mysterious
lockups perhaps similar to Kevin O (fbsd)'s problems).

For IPsec, I am running transport mode from client to server; I am not
doing any tunnel-mode across wireless at the moment.

  Do you run a strong connection?

when near the server, sometimes.   Across the 28.8 link, essentially
never.  Then I think things work, but it's too painful, and I really
like the write-behind caching of wd mode.

  I am running fairly close to the head of NetBSD-current, I will be
  updating that to head soon again.  My server is running i386 SMP at
  the moment and I do not appear to have any grief with coda on that
  front which is good (just a data point for peoples).

If you are in the mood, build and install cfs, and then try using
emacs in a cfs filesystem, which will create symlinks for emacs's own
advisory locks when modified.  I have been able to panic a 1.6-stable
system doing this, with a 'ref cnt' panic in vput (I think count was
zero when it should have been 1).  Both emacs-in-coda and emacs-in-cfs
seem to work.  Note that cfs makes symlinks to nowhere to store IVs,
as in .pvect_hex -> hex.  symlinks in the ciphertext fs don't seem to
have IVs (like the filenames themselves).

The operation that seems to hose me when over the 28.8 line is (no cfs
here):
$ cd /coda/home/gdt/foo/bar
$ mv /home/gdt/file . #from regular ffs on local disk
But I have not really isolated things.  Try having other competing
traffic on the link too.


Jan gave me hints to be able to checkpoint LOG/DATA/cache, so I will
be more willing to experiment - rolling back to stable venus with
hoarded bits is better than -init.

  I will have a look at doing some heavy CVS'ing on my setup and see
  what happens.  I have been planning to do this anyway as I am playing
  with a larger project.  Up til now my modus operandi is to "cvs co"
  a tree on the server and then hoard the data to my laptop, maybe do
  some small commits from the laptop to the cvs server when
  disconnected.  As I said, I have not had many problems that cannot be
  laid at the feet of a dirty shutdown or my fat fingers...

Do you have the _repository_ in Coda (shudder), or just your working
area?


CFS needs the following to play nice with coda:

  don't open files for write unless the user did, so that reading a
  file doesn't invoke store.  (unix semantics are that open for write
  and not writing does not cause 'modification',  but it does for coda)
  Without this, you get write-write conflicts from read-read operations.

  close files reasonably promptly, so one doesn't have stores hang
  until the next cfs access (gross patch to generated file)

--- cfs_fh.c.~1~	Wed Mar 20 12:57:56 1996
+++ cfs_fh.c	Mon Nov  8 11:19:22 1999
@@ -543,7 +543,9 @@
 		openfd=NULL;
 	}
 
+#if 0
 	if (mode==0) { mode=CFS_WRITE; }
+#endif
 	/* Phil Karn's hack for R/O file systems */
 	if ((fd=open(f->name,mode,0))<0 && errno == EROFS) {
 		mode = CFS_READ;        /* Force read and try again */
--- nfsproto_svr.c.~1~	Mon Nov  8 11:20:40 1999
+++ nfsproto_svr.c	Mon Nov  8 11:21:27 1999
@@ -166,5 +166,6 @@
 		fprintf(stderr, "unable to free arguments");
 		exit(1);
 	}
+	closeall();
 	return;
 }