On 06/01/2016 01:48 AM, Lu Fengqi wrote:
Only in the case of different root_id or different object_id, check_shared identified extent as the shared. However, If a extent was referred by different offset of same file, it should also be identified as shared. In addition, check_shared's loop scale is at least n^3, so if a extent has too many references, even causes soft hang up. First, add all delayed_ref to the ref_tree and calculate the unqiue_refs, if the unique_refs is greater than one, return BACKREF_FOUND_SHARED. Then individually add the on-disk reference(inline/keyed) to the ref_tree and calculate the unique_refs of the ref_tree to check if the unique_refs is greater than one.Because once there are two references to return SHARED, so the time complexity is close to the constant. Reported-by: Tsutomu Itoh <t-itoh@xxxxxxxxxxxxxx> Signed-off-by: Lu Fengqi <lufq.fnst@xxxxxxxxxxxxxx>
This is a lot of work for just wanting to know if something is shared. Instead lets adjust this slightly. Instead of passing down a root_objectid/inum and noticing this and returned shared, add a new way to iterate refs. Currently we go gather all the refs and then do the iterate dance, which is what takes so long. So instead add another helper that calls the provided function every time it has a match, and then we can pass in whatever context we want, and we return when something matches. This way we don't have all this extra accounting, and we're no longer passing root_objectid/inum around and testing for some magic scenario. Thanks,
Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
