On Tue, May 6, 2025 at 10:10 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Sun, Apr 27, 2025 at 12:39:14PM -0400, cel@xxxxxxxxxx wrote: > > NFSD can return 0 here, as at least one client implementation we > > are aware of (the Linux NFS client) treats 0 as meaning "CLONE has > > no alignment restrictions". > > Usuaully clone does have a restriction, though. > > > Meanwhile we need to consult the nfsv4 Working Group to clarify the > > meaning and use of the value of this attribute. > > Yeah, the attribute seems to be severly underspecified, i.e. it does > not even provide a unit that the value is in. My preference would be that it counts in bytes, basically the same what the Windows API |FSCTL_DUPLICATE_EXTENTS_TO_FILE| (see https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_duplicate_extents_to_file) does. > I think the only sane way out is an errate that makes 0 mean > "not specified" and then provides the byte unit and maybe some > other quirks. I agree, Technically not even an "errata", it's just logic... :-) FATTR4_CLONE_BLKSIZE==0 ----> no info FATTR4_CLONE_BLKSIZE==1 ----> no alignment restrictions FATTR4_CLONE_BLKSIZE>1 ----> use this alignment value One thing to consider would be to make |FATTR4_CLONE_BLKSIZE| perr-filesystem *AND* per-file, since modern filesystems may have a per-file *preferred* block size. > > + /* Linux filesystems have no clone alignment restrictions */ > > That is absolutely untrue as said above. FYI I've implemented Win32 |FSCTL_DUPLICATE_EXTENTS_TO_FILE| support in the Windows ms-nfs41-client NFSv4.2 driver via NFS CLONE, and so far didn't hit any alignment restrictions with Linux 6.6 exporting a btrfs filesystem... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@xxxxxxxxxxx \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
