Re: Feature Req: "mkfs.btrfs -d dup" option on single device

[David Sterba <dsterba@suse.cz>]

On Thu, Dec 12, 2013 at 10:57:33AM -0500, Chris Mason wrote:
> 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've asked to allow data=dup in mixed mode when Ilya implementd the
validations of balance filters. That's a convenient way how to get
mirrored data on a single device.

> 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.

It's not perfect yeah.

> 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.

I've been testing --mixed mode with various other raid profiles types as
far as I remember. Some bugs popped up, reported and Josef fixed them.