From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7387 invoked from network); 5 Mar 2021 09:51:17 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 Mar 2021 09:51:17 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 9620F9CA82; Fri, 5 Mar 2021 19:51:14 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id F0BA39CA68; Fri, 5 Mar 2021 19:50:42 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 355FA9CA68; Fri, 5 Mar 2021 19:50:39 +1000 (AEST) Received: from hop.toad.com (75-101-100-43.dsl.static.fusionbroadband.com [75.101.100.43]) by minnie.tuhs.org (Postfix) with ESMTPS id C8D909CA67 for ; Fri, 5 Mar 2021 19:50:36 +1000 (AEST) Received: from hop.toad.com (localhost [127.0.0.1]) by hop.toad.com (8.12.9/8.12.9) with ESMTP id 1259oWmj025190; Fri, 5 Mar 2021 01:50:32 -0800 To: "John P. Linderman" In-reply-to: References: <20210304212459.GA6303@eureka.lemis.com> <20210304212917.GB6303@eureka.lemis.com> Comments: In-reply-to "John P. Linderman" message dated "Thu, 04 Mar 2021 16:48:36 -0500." Date: Fri, 05 Mar 2021 01:50:32 -0800 Message-ID: <25189.1614937832@hop.toad.com> From: John Gilmore Subject: Re: [TUHS] tunefs -m 5% X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: TUHS main list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" John P. Linderman wrote: > I have several 12 TB disks scattered about my house. 5% of 12TB is 600GB. At one point in hystery, ext2 performance was reported to suffer badly if there was less than 5% of disk space available in an active filesystem. My naive belief, probably informed by older and wiser heads around Sun, was that when the file system was >95% full, ext2 spent a lot of time seeking around in free lists finding single allocatable blocks. And there were no built-in "defragmentation" programs that could easily fix that. Is that still a performance constraint in ext4, which has had a few decades to work out those edge performance issues? And if it's fixed, then to handle the "root needs lebensraum" argument, perhaps the default reserved percentage should be set to 1% (or 0.1%, which I think the tools do not currently support)? Or perhaps it should be min(1%,10GB) reserved for root, so the calculation works better on both large or small filesystems? And on file systems that aren't expected to have root logfiles and such in them, should the right default now be -m 0? How many zettabytes of storage could we make available to users in 2030, by improving this default from the 1980s now? John