Simplify copy-reflink code

[David Disseldorp]

On Fri, 5 Apr 2024 07:57:28 +0200, Ralph Boehme wrote:
...
> On 4/5/24 07:21, David Disseldorp wrote:
> > I don't think dup-extents should fallback to copy; with the initial
> > implementation we had VFS_COPY_CHUNK_FL_MUST_CLONE to make this
> > explicit. However, the MS-FSCC spec doesn't appear to state that cloning
> > is a hard requirement, only that it should be supported alongside
> > FILE_SUPPORTS_BLOCK_REFCOUNTING and that offsets+lengths need to be
> > "logical cluster boundary" aligned.  
> 
> MS-FSA 2.1.5.9.4 FSCTL_DUPLICATE_EXTENTS_TO_FILE makes it pretty clear 
> what should be done and that a fallback to data copy is not in scope.

Ah great, I was wondering why I couldn't find anything clear in MS-SMB2
or MS-FSCC...

> > We probably need to do some testing against modern ReFS to check some of
> > these questions.  
> 
> 
> I'm working with a customer who is testing with a Windows server with 
> ReFS where he uses a testing program [1] running on the client that 
> allows manual control over the operation and results confirm the spec: 
> no fallback, failure on non aligned IO request.
> 
> [1] https://github.com/tdewin/refs-fclone

Interesting, thanks! What about unaligned lengths when it covers the end
of a file? Btrfs has similar (FS block size) alignment restrictions for
clone, but will permit unaligned clone lengths when it corresponds to
the final extent. IIUC the existing MS-FSA pseudocode does't accept
any misalignment.

Cheers, David