I wrote:
--------
Here's a baffler:
System: Dataless 3/60 running 4.0.3 (with X11R4 active)
/, swap, /var, /tmp, a scratch file system, and a file system
containing /usr/bin and /usr/ucb are all on the local disk.
File systems for home directories, /usr, /usr/kvm, and /usr/local are
NFS mounted from the server.
My console window got the following message:
Jun 28 10:24:44 oedipus vmunix: /tmp: optimization changed from TIME to SP
ACE
Even though df shows:
/dev/sd0f 19431 257 17230 1% /tmp
Anybody know what did this and and how to reverse and prevent it?
I've seen this occasionally on another workstation (running NeWS
rather than X), but could never figure out the cause.
The answer:
-----------
The sticky bit was set on /tmp, which means you have to own a file to
remove it. I hope that in 4.1 the sticky bit follows System V
semantics, which are to remove a file from a sticky directory you have
to own the file or have write permission for it. Anybody checked?
If /tmp is sticky, the file /tmp/.getwd can't be removed by anybody
but the first uid to do a getwd() since boot time. This leads to a
proliferation of files /tmp/.getwda?????? which cause the file system
to become fragmented.
Fsck told me that the file system had 10% fragmentation. This will
cause space optimization to kick in even if the fragments are big.
Several people suggested that a transient file might have caused the
message and then have been gone when I checked. Since this is a
workstation, and nothing I was running would blat 20 Meg out to /tmp,
I consider that answer unlikely.
I found all those .getwd files just before getting mail from:
kensmith@cs.Buffalo.EDU (Ken Smith)
pbg@cs.brown.edu (Peter Galvin)
Thanks to auspex!guy@uunet.UU.NET (Guy Harris) for a code fragment
that convinced me that a fragmented but nearly empty file system could
tickle this.
And thanks to the rest of the cast:
Mike Walker <mike@tab00.larc.nasa.gov>
del@mlb.semi.harris.com (Don Lewis)
kevin@Corp.Sun.COM (Kevin Sheehan {Consulting Poster Child})
trinkle@cs.purdue.edu
david@srv.PacBell.COM (David St. Pierre)
"alex;923-4483" <alexl%daemon.cna.tek.com@RELAY.CS.NET>
As for reversing it, a tunefs on the unmounted file system can change
the optimization back. Of course, it would help to get the junk out
first or it will just change itself again.
-- Andy Sherman/AT&T Bell Laboratories/Murray Hill, NJ AUDIBLE: (201) 582-5928 READABLE: andys@ulysses.att.com or att!ulysses!andys What? Me speak for AT&T? You must be joking!
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:57 CDT