efb@suned1.UUCP (Everett F. Batey II) (10/12/89)
Over the past year we have been on a growing neighborhood ethernet .. now a dozen DECNET hosts, dozen TCP/NFS Suns,
untrusted bridges .. 802.3 HP3000s and finally a dual
homed VAX (ethernet and IMP). My main daytime use is
on a 4.0.1 windowed 3/60 dataless NFS Client.
The main server for this client is a 4.0.3 server,
though my work space is on a 3.3 Sun OS 3/160 server.
This is also where the clients get /var/spool/mail
( nfs,hard,intr .. rw ).
The bad part is unlike a few weeks ago .. ucb mail ..
Sunview mail both work very fast .. often I am frozen
15min to two hours waiting from the initial header until
the curses display of all the mail messages. Same for
Ctrl_U updates .. traffic, etherfind, perfmeters all
suggest there are no bandwidth problems over the bridges
between the server and client.
VERY TRULY, AT_MY_WITS_END, any ideas REALLY welcome, adjs
to NFS whatever .. /Ev/
--
The_Main_User (So Calif SunLUG | Vta-SB-SLO-DECUS)
efb@elroy.JPL.Nasa.Gov efb@suned1.UUCP efbatey@Vaxb.Navy.MIL
Statements, Opinions ... MINE ... NOT those of my US Employer argv%turnpike@Sun.COM (Dan Heller) (10/13/89)
In article <2497@suned1.UUCP> efb@suned1.navy.mil (Everett F. Batey II) writes: > The main server for this client is a 4.0.3 server, > though my work space is on a 3.3 Sun OS 3/160 server. > This is also where the clients get /var/spool/mail > ( nfs,hard,intr .. rw ). > The bad part is unlike a few weeks ago .. ucb mail .. > Sunview mail both work very fast .. often I am frozen > 15min to two hours waiting from the initial header until > the curses display of all the mail messages. Same for You're actually waiting that long? :-) I only have one idea about what could be happening. file locking. Mush now takes great lengths to lock mail files. With NFS and mail existing on a shared partition, sun's mail programs have obviously been modified to do something "new" with respect to file locking. The only way to find out if this is the problem is to comment out all the "locking" functions that mush uses (see lock.c). For sun's, that will be "flock()" calls. Also, don't define DOT_LOCK. this is not a solution! This is a recommendation to see if the problem (which I assume may be reliably reproduced) goes away. If so, then we need to investigate alternatives. I think there is a nfs-locking func that may be used, but don't know anything about it yet. Let's go from here. IF there are any people w/suns out there who are using the same configuration and/or environment described here, please speak up whether youare having the problem or not. dan <island!argv@sun.com> ----- My postings reflect my opinion only -- not the opinion of any company.
argv%turnpike@Sun.COM (Dan Heller) (10/13/89)
It just occured to me that you're running mush 6.4 -- please get the latest version (6.5.6) and see if that helps. For ftp access, it's on ucbvax:pub/mush-6.5.tar.Z. If you don't have ftp access, I can send it to you -- send mail to dheller@cory.berkeley.edu -- do *NOT* send me mail here or any other address!! dan <island!argv@sun.com> ----- My postings reflect my opinion only -- not the opinion of any company.