On Thu, Sep 1, 2016 at 12:47 PM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote:
> 2. Snapper's default snapshot creation configuration is absolutely > pathological in nature, generating insane amounts of background resource > usage and taking up huge amounts of space. If this were changed, you would > be a lot less dependent on being able to free up snapshots based on space > usage. That's diplomatic. They know all of this already though, but instead of toning down snapper defaults, they're amping up the voluming by enabling quotas instead. There is only one logical reason for this that I can thing of. They're trying to increase problem reports, presumably in order to smooth out noisy data, maybe even by getting better bug reports like Ronan's. But I think this is a specious policy. > It's poor choices like this that fall into the category of 'Ooh, this looks > cool, let's do it!' made by major distros that are most of the reason that > BTRFS has such a bad reputation right now. Over on Factory list, they're trying to have this two ways. First they're saying quotas are stable as they've implemented them in the Leap 4.4 kernel. And they consider the btrfs-progs man page warning that quotas aren't yet stable even in 4.7, and aren't recommended unless the user will use them, is a bug that should be removed from their copy of the man page. So, what are they using? Pulling out such warnings doesn't make upstream code backported to their 4.4 kernel magically stable. If they're using out of tree quota code, fine, remove the warnings. But then, what is this code? How does it interact with upstream kernels? -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
