Jesse Pollard writes:
> On Wed, 31 May 2000, Albert D. Cahalan wrote:
>> Keith Owens writes:
>>> "Albert D. Cahalan" <acahalan@cs.uml.edu> 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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:28 EST