On Wed, Sep 23, 2015 at 10:00:12PM +0800, Qu Wenruo wrote: > As it's already planned, and I think it will need new incompact flag > anyway, or old kernel can easily remove/convert desired profile.
The usecase with the old kernel is colser to the rescue scenario than regular use. We do have support for read-only compatibility (grep for COMPAT_RO), so all of this might be covered by such an incompat flag. > So what about adding new ROOT_ITEM members to record data/meta profile? The profile is not the only property we'd like to add. It is be possible to add it to btrfs_root_item in a safe way, like the new send related items. > I'm not a big fan to use xattr and it's quite easy to modify from user > space, and not completely confident with the possible concurrency about > xattr modification with chunk allocation. The point is to be able to modify it from the userspace, but it's done in a safe way. The xattrs are in their own namespace and have handlers taht propagate the changes anywhere it's needed. The idea is to cache the values along the in-memory structures and only update them via the handlers. > And from the logical level, xattr is at the same level as inode, but > subvolume is definitely at a higher level, even it's normally treated as > directory. > So for me, I'd like to record it into root_item, not as sub xattr, even > it may need an extra ioctl to handle it. The xattrs give us extensibility that does not require changes in the size of root_item structure. Basically, the unknown and unsupported xattrs (properties) are invisible in the b-tree. > Anyway, I'm just a new comer for this feature, it's completely OK to > ignore my stupid ideas. No worries. We had similar discussions in the past, I proposed special ioctls first but then the xattrs were found more suitable. So we're letting you know the status but there's still some chance that we missed something and you can point it out. -- 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
