Re: [PATCH 3/9] btrfs: track original extent subvol in a new inline ref

From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz
Cc: Boris Burkov <boris@bur.io>,
	linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 3/9] btrfs: track original extent subvol in a new inline ref
Date: Thu, 11 May 2023 08:07:44 +0800	[thread overview]
Message-ID: <70eaeae9-ec51-d033-4810-9ed0699fbc76@gmx.com> (raw)
In-Reply-To: <20230510165705.GV32559@twin.jikos.cz>

On 2023/5/11 00:57, David Sterba wrote:
> On Wed, May 03, 2023 at 11:17:12AM +0800, Qu Wenruo wrote:
>> On 2023/5/3 08:59, Boris Burkov wrote:
>>> In order to implement simple quota groups, we need to be able to
>>> associate a data extent with the subvolume that created it. Once you
>>> account for reflink, this information cannot be recovered without
>>> explicitly storing it. Options for storing it are:
>>> - a new key/item
>>> - a new extent inline ref item
>>>
>>> The former is backwards compatible, but wastes space, the latter is
>>> incompat, but is efficient in space and reuses the existing inline ref
>>> machinery, while only abusing it a tiny amount -- specifically, the new
>>> item is not a ref, per-se.
>>
>> Even we introduce new extent tree items, we can still mark the fs compat_ro.
>>
>> As long as we don't do any writes, we can still read the fs without any
>> compatibility problem, and the enable/disable should be addressed by
>> btrfstune/mkfs anyway.
>
> There a was a discussion today how the simple quotas should be enabled.
> We have 3 ways, ioctl, mkfs and btrfstune. Currently the qgroups can be
> enabled by an ioctl and newly at mkfs time.
>
> For squotas I'd do the same, for interface parity and because the quotas
> are a feature that allows that, it's an accounting layer on top of the
> extent structures. Other mkfs features are once and for the whole
> filesystem lifetime.

OK, ioctl is still better than mount option, so it's acceptable to me.

The other concern is, would this be compat_ro or incompat?

I want to ensure extent tree change still to be compat_ro, which may
requires us to make sure unsupported compat_ro flags would not cause any
extent tree read.

We have already skipped bg items search, but we still read the extent
tree root.

Thanks,
Qu
>
> You suggest to avoid doing ioctl, which I'd understand to avoid all the
> problems with races and deadlocks that we have been fixing. Fortunatelly
> the quota enable ioctl is extensible so we can add the squota
> enable/disable commands and built on top of the whole quota
> infrastructure we already have.
>
> In addition the mkfs enabling should work too, like for qgroups. I think
> we should support the use case when the need to start accounting data
> comes later than mkfs and unmounting the filesystem is not feasible.
>
> This also follows the existing usage of the generic quotas that can be
> enabled or disabled as needed.