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