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;
}
