From owner-freebsd-questions@freebsd.org Wed May 6 22:41:37 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 111B82E184D for ; Wed, 6 May 2020 22:41:37 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from mail.steinkamm.com (mail.steinkamm.com [194.127.175.194]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "steinkamm.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49HWmH4Lc6z4JWZ for ; Wed, 6 May 2020 22:41:35 +0000 (UTC) (envelope-from arne@Steinkamm.COM) Received: from trajan.stk.cx (trajan.stk.cx [10.8.8.110]) by basis.steinkamm.com (8.15.2/8.15.2) with ESMTPS id 046MfUSI081096 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 7 May 2020 00:41:31 +0200 (CEST) (envelope-from arne@steinkamm.com) Received: from trajan.stk.cx (localhost [127.0.0.1]) by trajan.stk.cx (8.15.2/8.15.2) with ESMTPS id 046MfUhm021766 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 7 May 2020 00:41:30 +0200 (CEST) (envelope-from arne@trajan.stk.cx) Received: (from arne@localhost) by trajan.stk.cx (8.15.2/8.15.2/Submit) id 046MfQR6021692; Thu, 7 May 2020 00:41:26 +0200 (CEST) (envelope-from arne) Date: Thu, 7 May 2020 00:41:26 +0200 From: Arne Steinkamm To: Bob Proulx Cc: freebsd-questions@freebsd.org, arne@steinkamm.com Subject: Re: redesignde the unix-like system directory Message-ID: <20200506224126.GJ82984@trajan.stk.cx> Reply-To: arne@Steinkamm.COM References: <83788746a7d8a802d8af4b582e00827166febd1a.camel@tom.com> <9a387b42-8da5-2968-24ba-754c3e461252@kicp.uchicago.edu> <20200506151230.GI82984@trajan.stk.cx> <20200506134457056426360@bob.proulx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200506134457056426360@bob.proulx.com> User-Agent: Mutt@Trajan/1.12.1 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on basis.steinkamm.com X-Rspamd-Queue-Id: 49HWmH4Lc6z4JWZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of arne@Steinkamm.COM has no SPF policy when checking 194.127.175.194) smtp.mailfrom=arne@Steinkamm.COM X-Spamd-Result: default: False [0.09 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[arne@Steinkamm.COM]; NEURAL_HAM_MEDIUM(-0.57)[-0.573,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Steinkamm.COM]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-0.54)[-0.537,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.00)[country: DE(-0.02)]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[freebsd-questions@Steinkamm.COM,arne@Steinkamm.COM]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34646, ipnet:194.127.175.0/24, country:DE]; FROM_NEQ_ENVFROM(0.00)[freebsd-questions@Steinkamm.COM,arne@Steinkamm.COM]; RCVD_TLS_ALL(0.00)[] 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 22:41:37 -0000 On Wed, May 06, 2020 at 01:55:47PM -0600, 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 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. Exact and thanks to answer the question. I saw this in a productive environment once and was really impressed that "professional services" lack the knowledge how filesystem traversal in a *ix environment works. Last time I was working with kernel sources (many years ago) namei(9) made a traversal on each call starting from the filesystems root inode. So a hanging nfs mount directly in a filesystems root is a real show stopper. FreeBSD is a real Unix with a history back to edition 6 at Bell Labs. So virtually all books ever written about Unix in the last 48 years are helpfull. There are many (!) real good books which do not have "Linux" or "FreeBSD" in their name which are more than worth to be read about basis system administration concepts. And to make the loop back to the topic: You need more than valid reasons to change hier(7) and break this heritage! Copying Android seems not to be a valid reason in this context. .//. Arne -- Arne Steinkamm | Home: Mail: arnesteinkammcom