On Tue, Mar 19, 2019 at 02:04:18PM +0800, Qu Wenruo wrote: > This new tree block flag is to indicate the tree block belongs to a log > tree. > > For btrfs on-disk format, there are several different trees could use > the same owner number: > - ordinary subvolume tree > - log tree for ordinary subvolume > - reloc tree for ordinary subvolume > > It's possible to do the backref walk or use the content to determine the > real owner of the tree block. > But backref walk is too expensive, content detection is not reliable. > > So adding a new flag to explicitly show the owner of log tree. > > Thankfully, tree-checker hasn't checked header flags yet, and there is > no real user for this flag yet. > So we don't need to introduce any compatibility flag for this > modification. I think we can't simply skip the backward compatibility here, this is a change of on-disk format and at least we have to understand what can go wrong when the combinations of new/old kernel/fs are used. > The introduction of this new flag makes tree block owner easier to > distinguish, making life easier for: > - tree checker on log tree > Log tree could contain some items impossible for regular trees > - performance profiler > Now it's much easier to distinguish log tree. So is this for enhanced correctness or performance helper? I'd tend to skip the performance part for now, it's not convincing argument for the on-disk change. And for the correctness I'd like more details, but the idea sounds good in general.
