Simplify copy-reflink code
David Disseldorp
ddiss at samba.org
Tue Apr 2 09:26:21 UTC 2024
Hi Ralph!
On Tue, 2 Apr 2024 09:49:57 +0200, Ralph Boehme wrote:
> Hi David!
>
> If you have the time, can you please take a look at
>
> https://gitlab.com/samba-team/samba/-/merge_requests/3566 ?
>
> I'm basically adding copy-reflink support to vfs_default alongside a new
> option "filesystem reflinks" that sets FILE_SUPPORTS_BLOCK_REFCOUNTING
> in the share capabilities if enabled..
>
> This works on eg ZFS by just setting "filesystem reflinks = yes".
> vfs_btrfs still sets FILE_SUPPORTS_BLOCK_REFCOUNTING if the module is
> configured, so there's no behaviour change for btrfs. But for other
> filesystems we have the choice of either setting
> FILE_SUPPORTS_BLOCK_REFCOUNTING in the module or relying on the new option.
>
> I had initially spotted a bug in vfs_btrfs and after fixing that [1], I
> realized that requiring all VFS modules to explicitly code copy-reflink
> support into them is not ideal and just moving it to vfs_default
> simplifies the modules a lot. The branch still contains the commit and
> its revert to demonstrate the problem.
>
> tl;dr:
>
> no change in behaviour, great simplification.
Sounds good to me, although I'll need a bit of time this week to take a
look (and do some testing). If it's passing the copy-chunk & dup-extent
torture tests on a btrfs-backed share, then I'm confident that it should
be fine. However, my confidence in the tests is reduced - I thought they
exercised the BTRFS_IOC_CLONE_RANGE fallback code-path, so should have
caught [1]. Perhaps it's just that nobody tests atop btrfs?
Cheers, David
> [1]
> <https://gitlab.com/samba-team/samba/-/merge_requests/3566/diffs?commit_id=48d8b9c7ad528790b24de5b1ccbfd8b04a2622cf>
More information about the samba-technical
mailing list