On 2018/10/4 下午4:07, Anand Jain wrote: > >> we >> already expect log tree root generation always to be super block >> genration + 1. > > This is close to what I was looking for by reading the cover-letter, > basically what is the impact/bug by not populating it?
Nothing really. Both kernel and btrfs-progs completely ignore it. > but can you > explain more, I wonder how was check working so long then? For btrfs-progs, the behavior will not change at all. It still assume log tree root's generation is super geneartion + 1. And if doesn't match reports a transid mismatch error. For kernel, super validation checker will do such generation check earlier. So instead of reporting transid mismatch and then btrfs_log_recover error, it will report log tree is bad. > >> But it could be later used to detect log tree corruption early. > > If there is no impact/bug its rather a good idea to change this when > the early log tree corruption detection part is ready. So that there > is absolute clarity. > > The reason why I am grossly wary is - we have incomplete business > about how do we handle the write-hole, say raid1 to begin with. If the solution is going to rely on log tree, then the patch shouldn't affect anyone. The main purpose here is to make the log_root_transid to follow all other generation behavior (root, chunk). Nothing to really affect users. Thanks, Qu > > Thanks, Anand
signature.asc
Description: OpenPGP digital signature
