Hi, On 07/08/2011 12:29 AM, Hugo Mills wrote: > Hi, Jan, > > On Thu, Jul 07, 2011 at 05:48:33PM +0200, Jan Schmidt wrote: >> these ioctls make use of the new functions initially added for scrub. they >> return all inodes belonging to a logical address (BTRFS_IOC_LOGICAL_INO) and >> all paths belonging to an inode (BTRFS_IOC_INO_PATHS). > > I've not read this patch in detail, so I may have missed something, > but why do we need new ioctls for these functions, when we have > BTRFS_IOC_TREE_SEARCH, which will allow us to perform the same two > operations using existing kernel-side infrastructure? > > Hugo.
Note that those ioctls do a lot more than just one tree search. You are right, we could implement all this with (quite a few) BTRFS_IOC_TREE_SEARCH ioctls. Especially resolving all file system paths for an inode needs really a lot of searches. I like to have logic requiring deep knowledge of the internals of btrfs trees in kernel, generally. Not to mention that this way we are safe to run this on a file system under load and still can get consistent results. Last but not least, if we want to use this code for general error reporting to the kernel log (e.g. by scrub), we need all the resolving code in kernel anyway. So I'd like to provide that functionality to user space, too. -Jan -- 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
