On Tue, Jan 10, 2017 at 08:35:26AM +0800, Qu Wenruo wrote: > That depends on how independent the "core" btrfs part is. > > If completely independent,(Don't ever has any page/VFS/race code) I'm > completely fine with that. > > But the problem is, at least from current code base, even btrfs_path > structure has quite a lot kernel facilities, mainly locks. > (Just check the different size of btrfs_path in kernel and btrfs-progs) > > So although the idea itself is very nice, but the practice may be quite > hard. > > That's why I prefer current btrfs-progs method, because it's more close to > the core of btrfs algorithm, unlike kernel, which is a superset. > In this case, I prefer to let kernel use and expand btrfs-progs code, other > than pull in a superset from kernel.
[snip] > While most of the bugs I found in RAID5/6 and dev-replace are all related to > race, which doesn't ever exist in btrfs-progs. > (That's why I love btrfs-progs so much than the kernel part) > > So the problem is still how independent we can extract the core functions. > > Thanks, > Qu I think you're getting too hung up on scrub/device replace. It doesn't have to be an all-or-nothing thing. If the scrub code is too insane or broken to pull in, then we can probably get away with a clean reimplementation in btrfs-progs if we really want to. I think for a majority of the Btrfs code, locking and other kernel-specific stuff won't be too distracting. A good starting point might be the core B-tree code. -- 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
