Alexander, thanks for addressing the issues. >> __get_cur_name_and_parent() >> if we decided to call get_first_ref() on the send_root (due to ino < >> sctx->send_progress), do we really need to call did_overwrite_ref()? >> Because it will just lookup the send root again. I mean if we know >> that this inode has been already handled, then it's not an orphan >> anymore, so no need for this additional check. If my understanding is >> wrong, pls give some small example? > get_first_ref does not return the current state. It returns the > permanent state. The result of did_overwrite_ref however depends on > the current send progress. There is however some room for optimization > here. In many cases, I did not think much about double tree lookups > due to the different calls, as I wanted it to work first and later > optimize it. One possible optimization for example would be to cache > the results of lookups. But only for functions which return permanent > state, e.g. get_inode_info. So do you think my understanding is correct that if (ino < sctx->send_progress), then both functions will return the same value? Or perhaps: if (ino < sctx->send_progress), then no need to check anymore the did_overwrite_ref(), because we have handled that already? I think that the call to did_overwrite_ref() is relevant only as long as we haven't handled this ino. After that, we are good...I think.
I'm not saying the code has be changed/optimized at this point, just testing my understanding:) >> struct btrfs_root_item: >> what is the difference between existing "generation" field that you >> mimic in generation_v2 and "ctransid"? (I know I need to study the >> root tree code). > Did you read the comments for btrfs_root_item and > btrfs_read_root_item? They should answer your question. Yes, I read the comments, but they address only "generation" and "generation_v2", which I understand. Basically, I don't understand how "generation" differs from ctransid (I need to dig more there). Thanks! Alex. >> >> Thank you, >> Alex. > Big thanks for your reviews :) > I pushed a new version of the kernel and progs side. The branches are > now "for-chris" -- 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
