Michael Göhler posted on Fri, 08 Nov 2013 00:45:32 +0100 as excerpted: > The use case for that is to set quotas for the child subvolumes.
Quite apart from the main thread subject, you're aware that there are major bugs with btrfs quotas/qgroups ATM, right? I'd certainly be wary of depending on them for anything at the distribution level you're discussing. The known quota bugs appear to be in two areas and may or may not be related. First, people have been complaining about huge and unaccounted memory usage on the order of multiple gigabytes while using quotas. I believe one related memory leak has recently been fixed (tho I'm not sure the fix is actually in mainline yet, it's that new), but there could well be more. Second, people are reporting negative quota numbers. Apparently this is the result of deleting snapshots or turning off qgroups on some subvolumes/snapshots but not others and goes away when the quotas are fully rescanned, but that's a time-intensive process on multi-terabyte spinning rust partitions. Again, there's work being done to address the issue, but it's nothing I'd want to rely on at this point. Given the above situation, I'd strongly suggest leaving the quota feature off on btrfs at this point, certainly at the distro level. If individuals want to test it that's fine, as long as they know the risk (which given that btrfs itself remains officially experimental, is simply a known stronger area of the risk that continues to apply to testing btrfs as a whole), but I'd argue it's inappropriate for distro level at this point. If quotas are dictated by the use-case, there are other more stable filesystem options available with stable quota support. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
