Re: Does /var/shm still need to be mounted?

From: Albert D. Cahalan (
Date: Wed May 31 2000 - 12:07:41 EST

Jesse Pollard writes:
> On Wed, 31 May 2000, Albert D. Cahalan wrote:
>> Keith Owens writes:
>>> "Albert D. Cahalan" <> wrote:
>>>> Thomas Molina writes:

>>>>> 1. Why is /var/shm such a bad place?
>>>> Just like the proc and devfs filesystems, this belongs at the top.
>>>> It really doesn't fit within anything else. Besides, flatter trees
>>>> are faster and easier to navigate. So, mount it on /shm.
>>> As long as getcwd() does a tree walk up to /, mounting anything on a
>>> directory directly under / is not a good idea. I have seen getcwd()
>>> hang because an NFS directory was mounted as /xxx instead of /nfs/xxx .
>> That looks like a network filesystem problem. If the "server" for
>> /shm goes down, you won't be worried about getcwd() anymore.
> It doesn't directly relate to the netowrk file system other than it
> has a tendency to lock the directory containing the mount point. If
> getcwd is used in a different directory tree than the nfs tree it hangs
> when it reaches the common directory tree (/ in this case).
>> We already have /proc, which isn't causing getcwd() hangs.
>> Besides, Linux has a real getcwd() system call.
> /proc is a local file system, as is root; so it doesn't have the same
> failure context.

/shm is a local file system too. It is like /proc.

If /shm or /proc fails, your kernel is _already_ crashing.
You are more likely to have / fail, assuming it is on a real disk.

It is just lame to worry about in-memory filesystems failing.
You might as well worry about random page table corruption.
Failure most likely means you need more reliable hardware.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:28 EST