public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC] btrfs: reflink: disable cross-subvolume clone/dedupe for simple quota
Date: Thu, 21 Mar 2024 12:34:27 +0500	[thread overview]
Message-ID: <20240321123427.73cab342@nvm> (raw)
In-Reply-To: <74730c411b0fd87484c8d894878c5cd8bac1d434.1710992258.git.wqu@suse.com>

On Thu, 21 Mar 2024 14:09:38 +1030
Qu Wenruo <wqu@suse.com> wrote:

> Unlike the full qgroup, simple quota no longer makes backref walk to
> properly make accurate accounting for each subvolume.
> 
> Instead it goes a much faster and much simpler way, anything modified by
> the subvolume would be accounted to that subvolume.
> 
> Although it brings some small accuracy problem, mostly related to shared
> extents between different subvolumes, the reduced overhead is more than
> good enough.
> 
> Considering there are only 2 ways to share extents between subvolumes:
> 
> - Snapshotting
> - Cross-subvolume clone/dedupe
> 
> And since snapshotting is the core functionality of btrfs, we will never
> disable that.
> 
> But on the other hand, cross-subvolume snapshotting is not so critical,

I think you meant cross-subvolume clone/dedupe in this case ^

> and disabling that for simple quota would improve the accuracy of it,
> I'd say it's worthy to do that.
> 
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>  fs/btrfs/reflink.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> ---
> [REASON FOR RFC]
> I'm not sure how important the cross-subvolume clone functionality is in
> real-world.
> 
> But considering squota is mostly designed for container usage, in that
> case disabling cross-subvolume clone should be completely fine.

Use case that comes to mind, create multiple LXC guests as snapshots from the
template container. They run for a few months, and then you upgrade OS and
software in each, using "apt dist-upgrade", to the latest releases.

Now it would be neat to be able to run dedupe on them to bring disk usage back
to about that of a single container, since the OS and newly installed files
would be mostly the same in all of them.

It also could be that the containers are managed by different users or
customers, in which case recreating them from template on every new OS releases
would not be feasible, and upgrading each separately is the only option.

> diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
> index 08d0fb46ceec..906cb6166b67 100644
> --- a/fs/btrfs/reflink.c
> +++ b/fs/btrfs/reflink.c
> @@ -15,6 +15,7 @@
>  #include "file-item.h"
>  #include "file.h"
>  #include "super.h"
> +#include "qgroup.h"
>  
>  #define BTRFS_MAX_DEDUPE_LEN	SZ_16M
>  
> @@ -350,6 +351,19 @@ static int btrfs_clone(struct inode *src, struct inode *inode,
>  	u64 last_dest_end = destoff;
>  	u64 prev_extent_end = off;
>  
> +	/*
> +	 * If squota is enabled, disable cloning between different subvolumes.
> +	 *
> +	 * As clone/reflink/dedupe is the only other way to share data between
> +	 * different subvolumes other than snapshotting.
> +	 * With it disabled, squota can be way more accurate.
> +	 */
> +	if (btrfs_qgroup_mode(fs_info) == BTRFS_QGROUP_MODE_SIMPLE) {
> +		if (BTRFS_I(src)->root->root_key.objectid !=
> +		    BTRFS_I(inode)->root->root_key.objectid)
> +			return -EXDEV;
> +	}
> +
>  	ret = -ENOMEM;
>  	buf = kvmalloc(fs_info->nodesize, GFP_KERNEL);
>  	if (!buf)


-- 
With respect,
Roman

  reply	other threads:[~2024-03-21  7:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-21  3:39 [PATCH RFC] btrfs: reflink: disable cross-subvolume clone/dedupe for simple quota Qu Wenruo
2024-03-21  7:34 ` Roman Mamedov [this message]
2024-03-21 13:25 ` David Disseldorp
2024-03-21 20:17   ` Qu Wenruo
2024-03-21 18:51 ` Josef Bacik
2024-03-21 19:08   ` Boris Burkov
2024-03-21 23:59     ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240321123427.73cab342@nvm \
    --to=rm@romanrm.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox