On 09/26/2016 07:39 PM, Omar Sandoval wrote: > On Sat, Sep 24, 2016 at 09:50:53PM +0200, Hans van Kranenburg wrote: >> On 09/23/2016 02:24 AM, Omar Sandoval wrote: >>> From: Omar Sandoval <osandov@xxxxxx> >>> >>> There are two separate issues that can lead to corrupted free space >>> trees. >>> >>> 1. The free space tree bitmaps had an endianness issue on big-endian >>> systems which is fixed by an earlier patch in this series. >>> 2. btrfs-progs before v4.7.3 modified filesystems without updating the >>> free space tree. >>> >>> To catch both of these issues at once, we need to force the free space >>> tree to be rebuilt. To do so, add a FREE_SPACE_TREE_VALID compat_ro bit. >>> If the bit isn't set, we know that it was either produced by a broken >>> big-endian kernel or may have been corrupted by btrfs-progs. >> >> This tekst will be read by anyone git blaming the source to find out >> what FREE_SPACE_TREE_VALID does, and maybe to find an answer to why >> their filesystem just got corrupted after using progs < v4.7.3, even if >> they run a new kernel which knows about this bit. >> >> Since the above text suggests this situation can be dealt with, the text >> is a bit misleading/incomplete. The construction with the bit requires >> active cooperation from whatever external tool that is changing the fs, >> to also flip this bit, to keep the filesystem from subsequently >> corrupting itself. >> >> So, starting to use this bit can only detect corruption by btrfs-progs >> before v4.7.3 once, and only exactly once. >> >> My suggestion is to just add a sentence like the following after "[...] >> may have been corrupted by btrfs-progs.": "Caution: Since btrfs-progs >> before v4.7.3 will not clear this bit after modifying the filesystem, >> keeping to use these older versions will again result in an inconsistent >> free space tree, without having an ability to detect this." > > Like I mentioned in the cover letter of the series, btrfs-progs won't > touch filesystems with the new bit set: > > ┌[root@silver ~] > └# btrfs --version > btrfs-progs v4.7.2 > ┌[root@silver ~] > └# btrfstune -x /dev/vdb1 > couldn't open RDWR because of unsupported option features (2). > Open ctree failed > > That's the point of compat bits. They're a whitelist rather than a > blacklist, and until we explicitly update btrfs-progs to allow that bit, > it will only allow read-only access. > > What happened with the earlier FREE_SPACE_TREE compat_ro bit is that we > mistakenly added it to the mask of supported compat_ro bits before it > was safe to do so. Aha! Now I see. If it sees something from the future, it just thinks: "whoa, not going to touch this". Thanks for your patience. :) -- Hans van Kranenburg -- 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
