On Fri, Sep 04, 2015 at 11:21:05AM +0800, Qu Wenruo wrote: > I'm happy and willing to add the relocating ability for btrfs-progs. > As that will provide a lot of flexibility, while the code should be > quite easy if I do it in a NOCOW method. > (Find a extent, copy it to other place, follow backref and modify) > > The only concern is, does it mean that we need to implement all the > features of btrfs kernel in user space tool?
I don't think we need a 1:1 feature parity. We might end up doing a one chunk relocation, but relocating an extent would be enough for a start. Doing the operations in userspace is easier in some respects as the data are not live, we can do different trade-offs, utilize readahead etc. Some operations might end up significantly faster and might be used as one-time actions eg. when converting multi-terabyte filesystem to another raid type. But this is a long-term goal. > And will it make the codes duplicated between kernel and progs? At this moment the code is not unified and we have to copy the code from kernel where needed. But as far as the code does not diverge, it'll be easier to use exact kernel sources in progs. Current versions of the common sources are not close enough, so we'd have to unify them first. -- 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
