On Tue, Apr 23, 2013 at 01:26:51PM +0200, Jan Schmidt wrote:
> --- a/fs/btrfs/qgroup.c
> +++ b/fs/btrfs/qgroup.c
> @@ -1494,10 +1494,14 @@ int btrfs_run_qgroups(struct btrfs_trans_handle *trans,
> {
> struct btrfs_root *quota_root = fs_info->quota_root;
> int ret = 0;
> + int start_rescan_worker = 0;
>
> if (!quota_root)
> goto out;
>
> + if (!fs_info->quota_enabled && fs_info->pending_quota_state)
> + start_rescan_worker = 1;
> +
> fs_info->quota_enabled = fs_info->pending_quota_state;
>
> spin_lock(&fs_info->qgroup_lock);
> @@ -1523,6 +1527,12 @@ int btrfs_run_qgroups(struct btrfs_trans_handle *trans,
> if (ret)
> fs_info->qgroup_flags |= BTRFS_QGROUP_STATUS_FLAG_INCONSISTENT;
>
> + if (start_rescan_worker) {
> + ret = btrfs_qgroup_rescan(fs_info);
btrfs_run_qgroups() is called from transaction commit and does BUG_ON
the return value.
btrfs_qgroup_rescan can return -EINPROGRESS if the rescan is in progress
and this is propagated back to trans commit. So the rescan triggered by
ioctl may cause a crash, unless I'm missing something.
The original question I've had is what sort of work does rescan do
because it's on the commit path and we don't want to add more work and
delay commit.
--
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
