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