The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: John Gilmore <gnu@toad.com>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] tunefs -m 5%
Date: Fri, 5 Mar 2021 10:32:15 -0500	[thread overview]
Message-ID: <YEJO/47hHmW1Pf8Q@mit.edu> (raw)
In-Reply-To: <25189.1614937832@hop.toad.com>

On Fri, Mar 05, 2021 at 01:50:32AM -0800, John Gilmore wrote:
> John P. Linderman <jpl.jpl@gmail.com> 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.

I'll point out that BSD FFS, at least in BSD 4.3, reserves 10% of the
file system for reserved blocks.  The reasoning gave was the same as
with ext2, which is performance suffers when the file system gets
really fully.  It really depends on the workload, but for the worst
case workloads, I've seen performance degradations happen earlier than
90% or 95% full.

Defragmentation is a hard problem, and it takes a *long* time, and or
chews up a lot of write cycles on flash, persistent memory, etc.  This
is especially true when the file system is very full, since there is
very little "swing space" available to copy data around, especially if
one is striving for the perfect state (e.g., a files are contiguous,
and the free space is contiguous).  Defragmentation utilities was
something that was only really popular on Windows systems, and in the
last, oh, ten years or so, even in the Windows world defrag is not
something you'll see in their disk utilities.

Ext4 has a defrag program, but it's really primitive, and it only
works by attempting to defrag *files*.  It doesn't try to defrag *free
space*, which is what you really need if you want to try to keep
performance up (and have space so as to keep files defragmented).  The
main reason why is that no one has sponsored work in this space ---
probably because it's way cheaper just to over-provision disk space.

If someone wants to try to implement it, I have a rough design about
how it might be done for ext4 --- but someone has to volunteer $$$ or
their own personal time in order to implement it.  And if it's only
for yourself, it's probably cheaper just to spend a extra few bucks to
buy a bigger disk.  I suspect it's for similar reasons that none of
the legacy Unix systems have defragmentation implemented either.  It's
not something which makes business case.

But hey, if someone is interested in working on it, I'll give the
standard open source answer --- patches gratefully accepted.  I'll
even give you a rough design as a starting point.  (And there's no
guarantee it will be a good idea for flash, given that seeks are
mostly free for flash, and write cycles are a consideration, and how
many people are still using HDD's today; newer operating systems, such
as Fuschia, have started designing for a world where they only need to
care about file systems for flash.)

Cheers,

					- Ted

  parent reply	other threads:[~2021-03-05 15:32 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-04 16:52 [TUHS] tabs vs spaces - entab, detab Will Senn
2021-03-04 16:59 ` Clem Cole
2021-03-04 18:31   ` arnold
2021-03-04 19:23     ` Nemo Nusquam
2021-03-04 19:37       ` Steve Nickolas
2021-03-04 19:50         ` Rob Pike
2021-03-04 21:20           ` Robert Clausecker
2021-03-04 21:25           ` Will Senn
2021-03-05  9:58             ` John Gilmore
2021-03-06 21:31               ` Dave Horsfall
2021-03-06 21:38                 ` Larry McVoy
2021-03-06 22:05                   ` Clem Cole
2021-03-15  3:02                     ` John Cowan
2021-03-15 18:15                       ` Steffen Nurpmeso
2021-03-15 21:19                         ` Bakul Shah
2021-03-15 23:47                           ` Steffen Nurpmeso
2021-03-16  3:10                             ` Earl Baugh
2021-03-15 21:08                       ` Dave Horsfall
2021-03-15 21:12                         ` Steve Nickolas
2021-03-15 21:24                           ` Dave Horsfall
2021-03-15 22:06                             ` Adam Thornton
2021-03-16 13:25                             ` arnold
2021-03-17  5:10                       ` Greg 'groggy' Lehey
2021-03-06 21:40                 ` Steve Nickolas
2021-03-04 18:48   ` emanuel stiebler
2021-03-05  0:44     ` John Cowan
2021-03-05  0:55       ` Larry McVoy
2021-03-05  1:09         ` George Michaelson
2021-03-05  1:21           ` Larry McVoy
2021-03-05  1:29             ` Richard Salz
2021-03-04 18:33 ` John P. Linderman
2021-03-04 21:24 ` Greg 'groggy' Lehey
2021-03-04 21:27   ` Will Senn
2021-03-04 21:29     ` Greg 'groggy' Lehey
2021-03-04 21:42       ` Will Senn
2021-03-04 21:48       ` John P. Linderman
2021-03-04 22:08         ` Andy Kosela
2021-03-04 22:12           ` Greg 'groggy' Lehey
2021-03-05 14:13             ` Steffen Nurpmeso
2021-03-05 20:24               ` John Cowan
2021-03-05 21:51                 ` Bakul Shah
2021-03-06 23:43                 ` Steffen Nurpmeso
2021-03-05  0:15           ` Jon Steinhart
2021-03-06 21:22           ` Dave Horsfall
2021-03-06 23:58             ` Bakul Shah
2021-03-07  0:03               ` Jon Steinhart
2021-03-07  0:25               ` Steve Nickolas
2021-03-07  9:16               ` Brantley Coile
2021-03-05  9:50         ` [TUHS] tunefs -m 5% John Gilmore
2021-03-05 15:01           ` Grant Taylor via TUHS
2021-03-05 15:32           ` Theodore Ts'o [this message]
2021-03-06  1:18             ` Greg 'groggy' Lehey
2021-03-06  1:52               ` Warner Losh
2021-03-06 21:45                 ` Dave Horsfall
2021-03-06 22:03                   ` Larry McVoy
2021-03-09  4:59                     ` Greg 'groggy' Lehey
2021-03-06 23:52                   ` David Barto
2021-03-06  1:16           ` Greg 'groggy' Lehey
2021-03-04 22:10     ` [TUHS] tabs vs spaces - entab, detab Greg A. Woods
2021-03-05  1:41 ` alan
2021-03-05  1:55 ` alan
2021-03-05  2:06   ` Will Senn
2021-03-05 17:08     ` Clem Cole
2021-03-05 17:19       ` Richard Salz
2021-03-05 19:39         ` Lawrence Stewart
2021-03-05 19:51           ` Dan Halbert
2021-03-08  1:52       ` Will Senn
2021-03-05 16:43 ` Scot Jenkins via TUHS
2021-03-05 22:23   ` Bakul Shah
2021-03-06 20:51 ` Dave Horsfall
2021-03-06 21:01   ` Jon Steinhart
2021-03-06 21:19     ` Larry McVoy
2021-03-06 22:01       ` Clem Cole

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YEJO/47hHmW1Pf8Q@mit.edu \
    --to=tytso@mit.edu \
    --cc=gnu@toad.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).