On Mon, Sep 26, 2016 at 04:13:29PM -0700, Omar Sandoval wrote: > > +/* > > + * Older kernels on big-endian systems produced broken free space tree > > bitmaps, > > + * and btrfs-progs also used to corrupt the free space tree. If this bit is > > + * clear, then the free space tree cannot be trusted. btrfs-progs can also > > + * intentionally clear this bit to ask the kernel to rebuild the free space > > + * tree. > > + */ > > Hm, I think I changed my mind about allowing btrfs-progs to clear the > bit intentionally. This creates a problem where we have a valid free > space tree, modify it with btrfs-progs and clear the bit, and then mount > it on an older kernel that doesn't check for the valid bit. If we really > wanted to, we could add yet another bit, say, FREE_SPACE_TREE_INVALID, > which prevents old kernels from mounting it, but I don't want to add > more hacks just because write support hasn't been implemented in progs > yet. That doesn't change this patch at all except for the comment here.
What you describe is possible to happen but still rare, the lowest recommended kernel for general FST feature use will be at least 4.9. We can describe the buggy kernel/tools combinations and recommended stafety steps, like clearing the cache manually etc. > Should I resend it or can this be fixed on applying? I can update the wording. -- 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
