Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 May 2020 15:19:16 -0500
From:      Valeri Galtsev <>
Subject:   Re: redesignde the unix-like system directory
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

On 5/6/20 2:55 PM, Bob Proulx wrote:
> Tim Daneliuk wrote:
>> Arne Steinkamm wrote:
>>>>> /cloud, various cloud applications
>>>>> /net,  network information and server information, etc.
>>> Looking at a flat layout like this one gives me a feeling, that
>>> most people forgot that it's a real bad idea to have a
>>> external mounted directory in the root directory... easy way to make
>>> a system unresponsive in case of a network problem.
>> Can you say a bit more about why this is so?
> Assume NFS for simplicity.  A mount point at the /nfsmount1 directory.
> Then run "ls -l /".  That needs to stat(2) each entry in / and hits
> /nfsmount1

Do people really do that? I kind of since forever use automounter or 
similar, net mounts are in subdirectories of


and - this is what _I_ do, not elegant thing, but convenient for my 
users - I make directories in / named after names of cross mounted 
machines, and put there symlinks to where automounter will mount 
exported from these machines directories, like

/machine1name/data1 --> ../mnt/machine1name/data1

Never had trouble you describe, and nicety of automounter is "nothing 
gets hang": once NFS server doesn't respond, mounts are unmounted 
seamlessly by automounter. And are mounted again when someone tries to 
access them and server is accessible.


> with stat(2) which if the nfs server is not responding
> cannot return an answer to the query.  A lot of daemons and cron jobs
> will assume that the file system root and all entries in there are
> available and will trigger this problem as a byproduct of their
> operations.  I am just describing "ls -l" as the simplest way to
> trigger the issue.  "NFS server not responding."  This can be a reason
> for a system load of hundreds or thousands as process slots fill up
> with stuck processes blocked waiting for I/O from an unresponsive server.
> However in the proposal I think the entries I quoted were for use as a
> subdirectory and not to have a mount point directly in root.
>>> I keep the traditional filesystem layout
> +1.  I prefer the traditional file system organization.
> Bob
> _______________________________________________
> mailing list
> To unsubscribe, send any mail to ""

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

Want to link to this message? Use this URL: <>