On 2019/3/20 上午2:23, David Sterba wrote: > 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. Currently since neither new fs nor old fs cares the unused bit in extent buffer headers, so it won't cause anything different. But if newer fs is going to rely on this bit to do tree-checker, then we should introduce a COMPATIBLE bit. Without that bit, kernel do no tagging, to be backward compatible. > >> 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. The chaos of eb->owner is, we have 3 root referring to one subvolid: ordinary root root->reloc_root root->log_root For ordinary root and reloc root, they're the completely the same content, so tree-checker needs no modification at all. But for log_root, its content is completely different, it can contain things like EXTENT_CSUM. With the ability to know if a tree block is a log tree one, we can finally implement owner based key type checker. E.g. if we have an EXTENT_CSUM item in subvol 256 and it's not a log tree eb, then we know something is definitely wrong. Thanks, Qu
Attachment:
signature.asc
Description: OpenPGP digital signature
