On 2015-11-26 12:38, David Sterba wrote:
My point was that if we know that there's a significant chance of either data corruption or a kernel crash when using a given feature with a given kernel, we should not turn on that feature for that kernel. For every other project I've ever seen, compatible means that you can be fairly certain that it won't crash, and won't destroy data. There is no excuse for knowingly making filesystems that will break the system.On Tue, Nov 24, 2015 at 03:21:19PM -0500, Austin S Hemmelgarn wrote:I think you mean 2.6.37 here. 67377734fd24c3 "Btrfs: add support for mixed data+metadata block groups"This brings up a rather important question: Should compat-X.Y mean features that were considered usable in that version, or everything that version offered? I understand wanting consistency with the kernel versions, but we shouldn't be creating filesystems that we know will break on the specified kernel even if it is mountable on it.IMO compat refers to the compatibility feature bits so it's whether the filesystem is mountable on a given version. Usability can be subjective. I assume the kernel versions in wide use match some of the long term branches. If it's k.org, we can submit the fixes and distros update their long term branches.
Also, expecting the distros to keep up with development given the pace at which BTRFS is moving is not all that realistic. Secondarily, at least Ubuntu has a habit of picking kernel versions that aren't marked LTS by kernel.org.
I'd say it would be a lot more helpful in the manpage than in the wiki (if you're reprovisioning a system, you don't necessarily have access to the wiki).A table of "is the feature usable" would be interesting but I think it's for wiki.
smime.p7s
Description: S/MIME Cryptographic Signature
