Re: Optimization changed on empty file system - SUMMARY

Date: Fri Jun 29 1990 - 12:25:11 CDT

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

    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) (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 <> (Don Lewis)
kevin@Corp.Sun.COM (Kevin Sheehan {Consulting Poster Child})
david@srv.PacBell.COM (David St. Pierre)
"alex;923-4483" <>

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:  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