linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Small fs
Date: Mon, 12 Sep 2016 04:54:24 +0000 (UTC)	[thread overview]
Message-ID: <pan$612d5$bc50d5d7$f1744b5$1e6b9281@cox.net> (raw)
In-Reply-To: CAJCQCtQz6cPhE1ciP5KJ2B5Ccy_5PSbzrmLmvh3rULoz_3h0bw@mail.gmail.com

Chris Murphy posted on Sun, 11 Sep 2016 21:03:04 -0600 as excerpted:

> The man page says:
> "The recommended size for the mixed mode is for filesystems less than
> 1GiB." But in this case recommended !=default which requires some mental
> gymnastics to rectify. If mixed-bg becomes obsolete upon enospc being no
> more likely with isolated block groups, then OK fine, but in the
> meantime...

On the bright side, the double-whammy of being under such tight 
filesystem size constraints, coupled with finding out you have less than 
half the space of the filesystem actually available due to default-mixed-
mode AND default dup-metadata (thus dup everything), gets eliminated, and 
barring problems with unbalanced chunk-sizes, you actually get to use 
most of capacity of the filesystem for actual files, instead of less than 
half of it.

=:^)

But I remain unconvinced that benefit outweighs the serious 
administrative headaches trying to run without mixed-mode on such small 
btrfs is likely to generate.  And what's worse, it's the same folks that 
are likely to have problems coping with either issue, but fixing the 
under-half-available-for-use (at the cost of filesystem resiliency) is a 
one-time thing, while the administrative issue of unbalanced chunks is 
likely to come back to bite them again and again.

But still, having people find they can fit only ~110 MiB in a 256 MiB 
btrfs, while with ext*, they can fit say 240 MiB in the same size 
filesystem, could be a bit more to try to explain to the technically 
under-literate, than the devs decided they were willing to deal with.  
Just saying it'd divided in chunks and another chunk won't fit is 
arguably easier than trying to explain why the filesystem will fit less 
than half of what the size of it suggests it should fit, IOW.

And I think that argument /was/ made, to some extent.  But the whole 
thing only came up because they found testing with small filesystems 
inconvenient due to the mixed-bg default, so rather than fix that by 
fixing the tests, they broke the previously sane defaults, instead.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2016-09-12  4:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-11 15:27 Small fs Imran Geriskovan
2016-09-11 15:32 ` Martin Steigerwald
2016-09-11 16:44   ` Duncan
2016-09-11 18:56     ` Imran Geriskovan
2016-09-11 19:21       ` Martin Steigerwald
2016-09-12 12:41         ` Austin S. Hemmelgarn
2016-09-12 14:09           ` Henk Slager
2016-09-12 14:12             ` Austin S. Hemmelgarn
2016-09-12 14:51             ` Chris Murphy
2016-09-12 14:56               ` Austin S. Hemmelgarn
2016-09-12  3:33       ` Duncan
2016-09-12 14:11         ` Imran Geriskovan
2016-09-12 17:43           ` Imran Geriskovan
2016-09-12 18:46             ` Imran Geriskovan
2016-09-12 18:55               ` Austin S. Hemmelgarn
2016-09-12 21:32                 ` Mike Fleetwood
2016-09-11 19:13     ` Martin Steigerwald
2016-09-11 19:46       ` Hugo Mills
2016-09-11 19:51         ` Martin Steigerwald
2016-09-12 12:45           ` Austin S. Hemmelgarn
2016-09-11 20:33 ` Chris Murphy
2016-09-12  2:00   ` Duncan
2016-09-12  3:03     ` Chris Murphy
2016-09-12  4:54       ` Duncan [this message]
2016-09-12 14:48         ` Chris Murphy
2016-09-13  4:25           ` Duncan
2016-09-12 12:54   ` Imran Geriskovan
2016-09-12 13:01     ` Austin S. Hemmelgarn

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='pan$612d5$bc50d5d7$f1744b5$1e6b9281@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.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).