lamy@ai.utoronto.ca (Jean-Francois Lamy) (12/11/89)
teraida!mikel@decwrl.dec.com (Mikel Lechner) writes: >kae@ihlpm.att.com (Kenneth A Edwards) writes: >With SunOS4.0 and later releases, Sun introduced a "performance >improvement" to the "getwd()" library call. The library function ends up >"stat()"ing virtually all your mounted filesystems every time your program >tries to compute its working directory. This is nearly guaranteed to hang >up any process makeing a "getwd()" call when a hard-mounted NFS filesystem >hangs. Using trace(1) you can easily determine that getwd() will not follow symbolic links. So you can avoid this problem by making sure that all NFS entries in /etc/fstab are actually symbolic links (i.e. mount on the symlink -- mount will follow the symlink at mount time and mount on the directory referenced by the symlink). Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
pearlman@rand.org (Laura Pearlman) (12/21/89)
Sun's getwd function can potentially stat all the mount points, all the current directory's siblings, and the siblings of all the current directory's ancestors in the process of determining the current working directory. I've written a few system calls to determine a file's filesystem id (since the fsid is a local concept, it's not necessary to contact a file's server to determine its fsid) and rewritten getwd to run stats only on directories that are on the same filesystem as the current directory. We've only been running my version of getwd for a short time, but so far it seems to have solved all our getwd-hanging problems. I could provide sources to my system calls and context diffs to getwd.c if anyone's interested. -- Laura Pearlman pearlman@rand.org
pearlman@rand.org (Laura Pearlman) (12/22/89)
In article <3880@brazos.Rice.edu> lamy@ai.utoronto.ca (Jean-Francois Lamy) writes: > Using trace(1) you can easily determine that getwd() will not follow > symbolic links. So you can avoid this problem by making sure that all NFS > entries in /etc/fstab are actually symbolic links (i.e. mount on the > symlink -- mount will follow the symlink at mount time and mount on the > directory referenced by the symlink). Perhaps I'm missing something obvious, but I don't see how this could possibly help the situation at all. If the /tmp/.getwd file is out of date, the getwd function stats each mount point found in /etc/mtab; when the mount program mounts a filesystem, it puts the real absolute pathname of the mount point (not the name of the symlink found in /etc/fstab) into /etc/mtab. -- Laura Pearlman pearlman@rand.org
ml@relay.eu.net (Marinko Laban) (01/09/90)
We have two Sun's 4/110 (SunOS 4.0), both with a 325 Mb disk. The two
Sun's are called process1 and process2.
Running a 'df' on process1 gives:
-----------------------------------------------------------------------
Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 5636 2624 2448 52% /
/dev/sd0g 64406 52201 5764 90% /usr
/dev/sd0h 175790 124076 34135 78% /usr/kti
process2:/usr/kti/proj2
235618 180069 31987 85% /usr/kti/proj2
-----------------------------------------------------------------------
A 'df' on process2:
-----------------------------------------------------------------------
Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 7608 2872 3975 42% /
/dev/sd0g 41092 37100 0 100% /usr
/dev/sd0h 235618 180152 31904 85% /usr/kti
process1:/usr/man 64406 52201 5764 90% /usr/man
process1:/usr/kti/tran
175790 124077 34134 78% /usr/kti/tran
process1:/usr/kti/prog
175790 124077 34134 78% /usr/kti/prog
process1:/usr/kti/etc
175790 124077 34134 78% /usr/kti/etc
process1:/usr/kti/proj1
175790 124076 34135 78% /usr/kti/proj1
process1:/usr/kti/applic
175790 124076 34135 78% /usr/kti/applic
process1:/usr/kti/home
175790 124076 34135 78% /usr/kti/home
-----------------------------------------------------------------------
So you see that we have cross-mounted the file-systems of both
computers. Now something weird happens ...
Suppose a user logs in into process1, and goes to the directory
/usr/kti/proj2. Note that this is physically a directory of process2. When
he tries to do a 'pwd' he gets the message "pwd: getwd: can't open .."
When the user logs in into process2, and does the same, no problem ...
When the user logs in on process2 and goes to /usr/kti/proj1, still no
problem...
So one might think that the access rights are wrong, but this is not the
case. We tried with ALL rights set to rwxrwxrwx of EACH FILE AND
DIRECTORY, but the problem still occured. Only the superuser didn't have
the problem.
We've looked to all possible files (fstab,mtab,exports etc.), but we
couldn't find the error. The Sun supplier in Holland doesn't give the
support you might expect, so we tried News for a possible answer.
If anybody knows what the answer may be, PLEASE RESPOND AS QUICK AS
POSSIBLE. Any suggestions are welcome.
Thanx.poffen@sj.ate.slb.com (Russ Poffenberger) (01/29/90)
In article <4251@brazos.Rice.edu> ktibv!ml@relay.eu.net (Marinko Laban) writes: >X-Sun-Spots-Digest: Volume 9, Issue 6, message 5 of 9 > >We have two Sun's 4/110 (SunOS 4.0), both with a 325 Mb disk. The two >Sun's are called process1 and process2. > > [stuff deleted] > >So you see that we have cross-mounted the file-systems of both >computers. Now something weird happens ... > >Suppose a user logs in into process1, and goes to the directory >/usr/kti/proj2. Note that this is physically a directory of process2. When >he tries to do a 'pwd' he gets the message "pwd: getwd: can't open .." > >When the user logs in into process2, and does the same, no problem ... >When the user logs in on process2 and goes to /usr/kti/proj1, still no >problem... I have seen the same type of thing. The problem was with the mount point itself for the NFS file system. Try this, unmount the filesystem in question, NOW check the permissions and make sure they are what you want (Owner, mode, group), then re-mount it. When a filesystem is NFS mounted, the permissions of the mount point should be completely overridden by the permissions of the mounted file system. This does not appear to be the case. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
jms@tardis.tymnet.com (Joe Smith) (02/02/90)
>Suppose a user logs in into process1, and goes to the directory >/usr/kti/proj2. Note that this is physically a directory of process2. When >he tries to do a 'pwd' he gets the message "pwd: getwd: can't open .." The same thing happened to us today. I found the problem by typing "cd .." over and over again until it failed. The problem was that "/.." (the root directory) was protected drwxrw---- instead of drwxr-xr-x. Do an "ls -ld /" on both systems to be sure. Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."