From: Hugo Mills <hugo@carfax.org.uk>
To: Chris Murphy <lists@colorremedies.com>
Cc: Imran Geriskovan <imran.geriskovan@gmail.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Feature Req: "mkfs.btrfs -d dup" option on single device
Date: Wed, 11 Dec 2013 08:09:02 +0000 [thread overview]
Message-ID: <20131211080902.GI9738@carfax.org.uk> (raw)
In-Reply-To: <6FD125A9-7975-4C34-88C7-95B11A39D054@colorremedies.com>
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]
On Tue, Dec 10, 2013 at 09:07:21PM -0700, Chris Murphy wrote:
>
> On Dec 10, 2013, at 8:19 PM, Imran Geriskovan <imran.geriskovan@gmail.com> wrote:
> >
> > Now the question is, is it a good practice to use "-M" for large filesystems?
> > Pros, Cons? What is the performance impact? Or any other possible impact?
>
> Uncertain. man mkfs.btrfs says "Mix data and metadata chunks together for more efficient space utilization. This feature incurs a performance penalty in larger filesystems. It is recommended for use with filesystems of 1 GiB or smaller."
That documentation needs tweaking. You need --mixed/-M for larger
filesystems than that. It's hard to say exactly where the optimal
boundary is, but somewhere around 16 GiB seems to be the dividing
point (8 GiB is in the "mostly going to cause you problems without it"
area). 16 GiB is what we have on the wiki, I think.
> I haven't benchmarked to quantify the penalty.
Nor have I.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- vi: The core of evil. ---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2013-12-11 8:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-10 20:31 Feature Req: "mkfs.btrfs -d dup" option on single device Imran Geriskovan
2013-12-10 22:41 ` Chris Murphy
2013-12-10 23:33 ` Imran Geriskovan
2013-12-10 23:40 ` Chris Murphy
[not found] ` <CAK5rZE6DVC5kYAU68oCjjzGPS4B=nRhOzATGM-5=m1_bW4GG6g@mail.gmail.com>
2013-12-11 0:17 ` Fwd: " Imran Geriskovan
2013-12-11 0:33 ` Chris Murphy
2013-12-11 3:19 ` Imran Geriskovan
2013-12-11 4:07 ` Chris Murphy
2013-12-11 8:09 ` Hugo Mills [this message]
2013-12-11 16:15 ` Chris Murphy
2013-12-11 17:46 ` Duncan
2013-12-11 14:07 ` Martin
2013-12-11 15:31 ` Imran Geriskovan
2013-12-11 23:32 ` SSD data retention, was: " Chris Murphy
2013-12-11 7:39 ` Feature Req: " Duncan
2013-12-11 10:56 ` Duncan
2013-12-11 13:19 ` Imran Geriskovan
2013-12-11 18:27 ` Duncan
2013-12-12 15:57 ` Chris Mason
2013-12-12 17:58 ` David Sterba
2013-12-13 9:33 ` Duncan
2013-12-17 18:37 ` Imran Geriskovan
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=20131211080902.GI9738@carfax.org.uk \
--to=hugo@carfax.org.uk \
--cc=imran.geriskovan@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.