Re: [nfsv4] Is NFSv4.2's clone_blksize per-file or per-file-system?

On Sat, Aug 9, 2025 at 1:12=E2=80=AFPM David Noveck <[email protected]> =
wrote:
>
>
>
> On Friday, August 8, 2025, Rick Macklem <[email protected]> wrote:
>>
>> On Fri, Aug 8, 2025 at 8:38=E2=80=AFPM Trond Myklebust <[email protected]=
m> wrote:
>> >
>> >
>> >
>> > On Fri, Aug 8, 2025 at 9:47=E2=80=AFPM Rick Macklem <rick.macklem@gmai=
l.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I'm looking at RFC7862 and I cannot find where it
>> >> states if the clone_blksize attribute is per-file or
>> >> per-file-system.
>> >>
>> >> If it is not in the RFC, which do others think it is?
>
>
>  Before you told us about ZFS,  I would have assumed per-fs.
>
> Given the uncertainty in the spec, you may wind up dealing clients that a=
ssume it is per-fs.
Actually, it looks like the Linux client assumes per-server.
(I'm going to ask over on linux-nfs@ to see what the implications of
getting the value wrong are. All I can see is that remap_file_range will
return EINVAL if a request isn't aligned.
--> The NFSv4.2 server would also reply EINVAL if the alignment is not
      correct, I think? (Actually RFC7862 says it must be aligned, but fail=
s
      to specify the error reply for this case. However it specifies
NFS4ERR_INVAL
      for other cases, so I think it makes sense to return that.)

      Hopefully someone over on linux-nfs@ will know if returning NFS4ERR_I=
NVAL
      for CLONE from the NFSv4.2 server will be more serious than a return =
of
      EINVAL for remap_file_range. (Other than a wasted RPC roundtrip.)

rick

>
> Although this is not a  catastrophe, you might want to file an errata rep=
ort explaining the negative consequences of assuming this is per-fs. It won=
't get into a spec for a long while but it does provide as much warning as =
you can right now .
>
>
>
>>
>> >> (Or maybe, if you have implemented CLONE,
>> >> which does your implementation assume?)
>> >>
>> >> In case you are wondering why I am asking,
>> >> it turns out that files in a ZFS volume can have
>> >> different block sizes. (It can be changed after the
>> >> file system is created.)
>
>
> The guy who allowed that probably thinks it's a helpful feature.  Sigh!
>
>> >>
>
>
>>
>> >> Thanks, rick
>> >>
>> >
>> > Yes, but since ZFS only supports filesystem level snapshots, and not a=
ctual file cloning, does that matter to anything?
>> ZFS now has a feature it calls block cloning, which does clone file rang=
es.
>> (It was only added recently. I do not know if the Linux port uses it yet=
?)
>>
>> rick
>>
>> >
>> > Cheers
>> >   Trond
>>
>> _______________________________________________
>> nfsv4 mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]