On Tue, Dec 19, 2017 at 06:45:11PM +0800, Qu Wenruo wrote: > btrfs_qgroup_inherit structure has two members, num_ref_copies and > num_excl_copies, to info btrfs kernel modules to inherit (copy) > rfer/excl numbers at snapshot/subvolume creation time. > > Since qgroup number is already hard to maintain for multi-level qgroup > scenario, allowing user to manually manipulate qgroup inherit is quite > easy to screw up qgroup numbers. > > Although btrfs-progs supports such inheritance specification, the > options are hidden from user and not documented. > So there is no need to allow user to manually specify inheritance in > kernel. > > Reported-by: Nikolay Borisov <nborisov@xxxxxxxx> And reported to Nikolay by me ;) My only objection is that we shouldn't rename the field names in the UAPI header. Let's just add a comment that the two counters are ignored. Besides that, Reviewed-by: Omar Sandoval <osandov@xxxxxx> > Signed-off-by: Qu Wenruo <wqu@xxxxxxxx> > --- > The only concern is, currently we don't have good tool to handle > inheritance of multi-level qgroups. > The only method to get qgroup numbers correct is to run a quota rescan. > > So there may be some case where experienced (well, mostly a developer) > user can use the hidden btrfs-progs options or manually craft an ioctl > to handle multi-level qgroups without costly rescan. If we want this functionality, we should add a specific ioctl for it instead of piggy-backing off of subvolume creation. Thanks! > --- > fs/btrfs/qgroup.c | 56 ++++++++++++++-------------------------------- > include/uapi/linux/btrfs.h | 4 ++-- > 2 files changed, 19 insertions(+), 41 deletions(-) -- 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
