From owner-freebsd-questions@freebsd.org Wed May 6 20:19:25 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 845D92DEC75 for ; Wed, 6 May 2020 20:19:25 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from kicp.uchicago.edu (kicp.uchicago.edu [128.135.20.70]) by mx1.freebsd.org (Postfix) with ESMTP id 49HScD2Jszz48Hx for ; Wed, 6 May 2020 20:19:24 +0000 (UTC) (envelope-from galtsev@kicp.uchicago.edu) Received: from [192.168.43.113] (unknown [172.58.142.164]) (Authenticated sender: galtsev) by kicp.uchicago.edu (Postfix) with ESMTPSA id 5B08C4E65F for ; Wed, 6 May 2020 15:19:18 -0500 (CDT) Subject: Re: redesignde the unix-like system directory To: freebsd-questions@freebsd.org References: <83788746a7d8a802d8af4b582e00827166febd1a.camel@tom.com> <9a387b42-8da5-2968-24ba-754c3e461252@kicp.uchicago.edu> <20200506151230.GI82984@trajan.stk.cx> <20200506134457056426360@bob.proulx.com> From: Valeri Galtsev Message-ID: <3f899735-1ed2-105c-1483-0450b8dcc7a3@kicp.uchicago.edu> Date: Wed, 6 May 2020 15:19:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200506134457056426360@bob.proulx.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49HScD2Jszz48Hx X-Spamd-Bar: +++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=uchicago.edu (policy=none); spf=none (mx1.freebsd.org: domain of galtsev@kicp.uchicago.edu has no SPF policy when checking 128.135.20.70) smtp.mailfrom=galtsev@kicp.uchicago.edu X-Spamd-Result: default: False [7.24 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[uchicago.edu : No valid SPF, No valid DKIM,none]; RECEIVED_SPAMHAUS_PBL(0.00)[164.142.58.172.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[164.142.58.172.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.4]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.997,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.15)[ip: (0.41), ipnet: 128.135.0.0/16(0.21), asn: 160(0.16), country: US(-0.05)]; NEURAL_SPAM_LONG(1.00)[1.000,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:160, ipnet:128.135.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; GREYLIST(0.00)[pass,meta]; RCVD_COUNT_TWO(0.00)[2] X-Spam: Yes X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 20:19:25 -0000 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 /net 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. Valeri > 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 > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > -- ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++