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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
