On Fri, May 26, 2017 at 1:44 PM, Sargun Dhillon <sar...@sargun.me> wrote: > This patchset has several improvements around the qgroups user-facing > API. It introduces two new ioctls for creating, and removing qgroups. > These ioctls have a new args structure that allows passing flags, and > some reserved fields for future expansion. The ioctls prevent some > operations around level-0 qgroups as well. > > The create operation prevents the creation of level-0 qgroups for > subvolumes that do not exist. The delete operations prevents the > deletion of level-0 qgroups that reference active volumes. > > In adddition, it adds a mount option "qgroup_auto_cleanup". > When this mount option is specified, qgroups will automatically > be cleaned up at volume deletion time. The reason this is a mount > option over a default behaviour is to avoid breaking old scripts > that rely on the behaviour of the existing APIs. Users can opt > into the new behaviour, as opposed it being an automated > trigger on newly created qgroups. Later on, we can introduce > a flag to subvol / qgroup create that marks the qgroup as > automatically created, and delete the qgroup as automatically > as well. > > Changes since v1: > * Remove creation of level-0 qgroups without subvol > * Add deprecation message for old API > > Sargun Dhillon (4): > btrfs: Fail on removing qgroup if del_qgroup_item fails > btrfs: Add new ioctl uapis for qgroup creation / removal > btrfs: Warn the user when the legacy btrfs_qgroup_create API is used > btrfs: Add qgroup_auto_cleanup mount flag to automatically cleanup > qgroups > > fs/btrfs/ctree.h | 1 + > fs/btrfs/ioctl.c | 117 > ++++++++++++++++++++++++++++++++++++++++++++- > fs/btrfs/qgroup.c | 79 ++++++++++++++++++++++++++++-- > fs/btrfs/qgroup.h | 6 ++- > fs/btrfs/super.c | 15 +++++- > include/uapi/linux/btrfs.h | 22 +++++++++ > 6 files changed, 230 insertions(+), 10 deletions(-) > > -- > 2.9.3 >
Hey, I wanted to see what people thought of this. This was the only way I saw forward that wouldn't break existing scripts, and would allow users to opt-in to this new behaviour. If y'all think that different semantics make sense, let me know, and I'll rev this patchset. -- 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
