Re: [nfsv4] Can NFSv4.2 operations be optional on a per server file system basis?

[Rick Macklem <[e-mail]>]

David Noveck wrote:
>I think the right error to return in the case in which allocate is implemented by the >server but not supported on a particular fs is NFS4ERR_SERVERFAULT. The case we >are talking about is an error that is not otherwise provided for, just as the >definition of that error states.
Just to clarify. Are you thinking that a return of NFS4ERR_SERVERFAULT to
an Allocate operation should be "normal expected behaviour" for a server
with a mix of exported file systems, where some can do Allocate and others
not?

rick
ps: It should be easy for the FreeBSD client to map NFS4ERR_SERVERFAULT
      to EINVAL, which is the error return expected from posix_fallocate()
      for this case.

On Sun, Oct 10, 2021, 3:33 PM Rick Macklem <[e-mail]<mailto:[e-mail]>> wrote:
Thomas Haynes wrote:
>> On Oct 10, 2021, at 7:07 AM, Rick Macklem <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Hi,
>>
>> I'm guessing the answer is "no", but I figured I'd ask just to make sure,
>> since RFC7862 states that operations are optional, but does not clarify
>> beyond that.
>>
>> So, if an NFSv4.2 server exports two file systems, where one of them can
>> perform the operation and the other cannot, is the server allowed to
>> reply NFS4ERR_NOTSUPP for the operation when attempted on files
>> in the file system that cannot perform the operation?
>>
>> Thanks, rick
>> ps: In FreeBSD, UFS can do Allocate, but ZFS cannot.
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/nfsv4
>
>
>Hi Rick,
>
>The answer is “no”.
That's what I thought.

>But the question is very interesting. NFS4ERR_INVAL might be the most appropriate of the allowed errors, but >pretty sure you do not want to be returning that.
Yea, EINVAL is the correct response for posix_fallocate(), but the Linux fallocate() uses ENOTSUPP and uses
EINVAL for lots of other things. Since returning EINVAL for a ZFS export was flagged as a bug by testers
during last week's Bakeathon, I'd agree that EINVAL wouldn't work.

>Of the not allowed errors, I think that NFS4ERR_OFFLOAD_DENIED is closest to what you want. You actually want an >NFS4ERR_ALLOCATE_DENIED. It would mean that ALLOCATE was supported, but not allowed for the given file.
>
>And I have no clue how easy it would be to drive that into the standard’s body any more. :-)
I think I'll just have to NFS4ERR_NOTSUPP for Allocate unless the server knows that all file systems
(and DSs for the pNFS case) can do it.

Thanks, rick
ps: Tom, is hs-anvil going to stick around on the Bat VPN for a while? I have a client side race/deadlock
      when testing against it and, if I come up with a fix, it would be nice to be able to test against it?

Tom

_______________________________________________
nfsv4 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nfsv4