On 03.11.2011 02:41, Li Zefan wrote: > (as this is going to be merged into mainline..) > >> +/* >> + * calls iterate() for every inode that references the extent identified by >> + * the given parameters. will use the path given as a parameter and return it >> + * released. >> + * when the iterator function returns a non-zero value, iteration stops. >> + */ >> +int iterate_extent_inodes(struct btrfs_fs_info *fs_info, >> + struct btrfs_path *path, >> + u64 extent_item_objectid, >> + u64 extent_offset, >> + iterate_extent_inodes_t *iterate, void *ctx) > > While trying to use this API, I found there's a big defect in this function. > > fs_tree 1 fs_tree 2 > \ / > \ / > \ / > \ / > node > | > | > leaf (EXTENT_DATA item) > > In the above case, the function will find only 1 reference. Hum. You are right. I'm convinced that I've been at this point months ago, only I cannot find code dealing with counts > 1 on nodes. I'll look for a fix in my branches or make a new one. I also recognized that some "btrfs_" prefixes are missing for the exported functions. I'm going to change this on the next iteration as well. Currently, this is more of a best-effort resolver. Support for delayed extents is missing, it should be used on commit roots to get a consistent state. For the userspace part, at least the simple scenario outlined isn't crucial as "btrfs inspect-internal logical-resolve" will find each of the two paths, depending on the subvolume path you specify. It never finds both, though, which I agree it should. Sigh, -Jan -- 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
