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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Aug 9, 2025 at 1:12 PM David Noveck <davenoveck@xxxxxxxxx> wrote:
>
>
>
> On Friday, August 8, 2025, Rick Macklem <rick.macklem@xxxxxxxxx> wrote:
>>
>> On Fri, Aug 8, 2025 at 8:38 PM Trond Myklebust <trondmy@xxxxxxxxx> wrote:
>> >
>> >
>> >
>> > On Fri, Aug 8, 2025 at 9:47 PM Rick Macklem <rick.macklem@xxxxxxxxx> 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 assume 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 fails
      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_INVAL
      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 report 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 actual file cloning, does that matter to anything?
>> ZFS now has a feature it calls block cloning, which does clone file ranges.
>> (It was only added recently. I do not know if the Linux port uses it yet?)
>>
>> rick
>>
>> >
>> > Cheers
>> >   Trond
>>
>> _______________________________________________
>> nfsv4 mailing list -- nfsv4@xxxxxxxx
>> To unsubscribe send an email to nfsv4-leave@xxxxxxxx





[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux