linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <clm@fb.com>
To: Duncan <1i5t5.duncan@cox.net>, <linux-btrfs@vger.kernel.org>
Subject: Re: Feature Req: "mkfs.btrfs -d dup" option on single device
Date: Thu, 12 Dec 2013 10:57:33 -0500	[thread overview]
Message-ID: <20131212155720.11479.7400@ret> (raw)
In-Reply-To: <pan$dd37b$1a442a8d$594e1d2e$ae5b97e3@cox.net>

Quoting Duncan (2013-12-11 13:27:53)
> Imran Geriskovan posted on Wed, 11 Dec 2013 15:19:29 +0200 as excerpted:
> 
> > Now, there is one open issue:
> > In its current form "-d dup" interferes with "-M". Is it constraint of
> > design?
> > Or an arbitrary/temporary constraint. What will be the situation if
> > there is tunable duplicates?
> 
> I believe I answered that, albeit somewhat indirectly, when I explained 
> that AFAIK, the fact that -M (mixed mode) has the effect of allowing -d 
> dup mode is an accident.  Mixed mode was introduced to fix the very real 
> problem of small btrfs filesystems tending to run out of either data or 
> metadata space very quickly, while having all sorts of the other resource 
> still available, due to inappropriate separate mode allocations.  And it 
> fixed that problem rather well, IMO and experience! =:^)
> 
> Thus mixed-mode wasn't designed to enable duped data at all, but rather 
> to solve a very different problem (which it did very well), and I'm not 
> sure the devs even realized that the dup-data it enabled as a side effect 
> of forcing data and metadata to the same dup-mode, was a feature people 
> might actually want on its own, until after the fact.
> 
> So I doubt very much it was a constraint of the design.  If it was 
> deliberate, I expect they'd have enabled data=dup mode directly.  Rather, 
> it was purely an accident, The fixed the unbalanced small-filesystem 
> allocation issue by enabling a mixed mode that as a side effect of 
> combining data and metadata into the same blocks, also happened to allow 
> data=dup by pure accident.

For me anyway, data=dup in mixed mode is definitely an accident ;)

I personally think data dup is a false sense of security, but drives
have gotten so huge that it may actually make sense in a few
configurations.

Someone asks for it roughly once a year, so it probably isn't a horrible
idea.

The biggest problem with mixed mode is just that it isn't very common.
You'll end up finding corners that others do not.  Also mixed mode
forces your metadata block size down to 4K, which does increase
fragmentation over time.  The new default of 16K is overall much faster.

-chris

  reply	other threads:[~2013-12-12 15:57 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
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 [this message]
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=20131212155720.11479.7400@ret \
    --to=clm@fb.com \
    --cc=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).