A year ago, on 7/30/2015, Chuck Lever said NFS/RDMA wasn't yet working
with NFSv4.1 and NFSv4.2, as a known issue.
I was able to use "vers=4.0" to get around the issue.
I see v4.2 seems to mount properly, but before switching over to it, I
wanted to see if it's considered stable, or still to be avoided.
Hi James-
> On Aug 18, 2016, at 12:09 AM, james harvey <[email protected]> wrote:
>
> A year ago, on 7/30/2015, Chuck Lever said NFS/RDMA wasn't yet working
> with NFSv4.1 and NFSv4.2, as a known issue.
>
> I was able to use "vers=4.0" to get around the issue.
>
> I see v4.2 seems to mount properly, but before switching over to it, I
> wanted to see if it's considered stable, or still to be avoided.
Can you tell why you'd like to use it? Which NFSv4.2 feature is interesting
to you?
I don't test it regularly, simply because
- The complete tests on each version take a long time to run
- NFSv4.2 features are all optional, and the Linux NFSv4.2 implementation
adds only a couple that probably won't be affected by RDMA. READ_PLUS will
need some attention at some point, but I think Anna is still polishing the
upper layer implementation.
- I don't have any specific tests for security labels, which add to the
size of the NFSv4 GETATTR receive buffer whether labels are actually
retrieved or not. So there is a little NFSv4.2 testing we get for free just
by using NFSv4.0.
- There's yet a lot of non-version-specific work to do on RPC-over-RDMA.
The main blocker before was support for bi-directional RPC, which all
minorversions of NFSv4 use after mv 1, and that should be working as well
as it does for NFSv4.1.
NFSv4.2 itself should work, but I might choose to stay with NFSv4.1 for
now if it were up to me, unless you have need of one of the new features.
For example, there is no standard specification describing how READ_PLUS
is supposed to work on RPC-over-RDMA (that's in the works).
--
Chuck Lever
Full sparse support would be nice, but certainly not critical. I'd
rather stay with what was considered least problematic.
I'm re-examining any workarounds we use, to see if any of the issues
have been resolved so any workarounds are no longer needed. As a
general rule, without a reason to do otherwise, I like letting
something run with defaults (where it would pick 4.2) rather than
overriding something.
So, with RDMA on 4.7.1+, no reason to stay on NFSv4.0 instead of NFSv4.1?
On Thu, Aug 18, 2016 at 11:26 AM, Chuck Lever <[email protected]> wrote:
> Hi James-
>
>
>> On Aug 18, 2016, at 12:09 AM, james harvey <[email protected]> wrote:
>>
>> A year ago, on 7/30/2015, Chuck Lever said NFS/RDMA wasn't yet working
>> with NFSv4.1 and NFSv4.2, as a known issue.
>>
>> I was able to use "vers=4.0" to get around the issue.
>>
>> I see v4.2 seems to mount properly, but before switching over to it, I
>> wanted to see if it's considered stable, or still to be avoided.
>
> Can you tell why you'd like to use it? Which NFSv4.2 feature is interesting
> to you?
>
> I don't test it regularly, simply because
>
> - The complete tests on each version take a long time to run
>
> - NFSv4.2 features are all optional, and the Linux NFSv4.2 implementation
> adds only a couple that probably won't be affected by RDMA. READ_PLUS will
> need some attention at some point, but I think Anna is still polishing the
> upper layer implementation.
>
> - I don't have any specific tests for security labels, which add to the
> size of the NFSv4 GETATTR receive buffer whether labels are actually
> retrieved or not. So there is a little NFSv4.2 testing we get for free just
> by using NFSv4.0.
>
> - There's yet a lot of non-version-specific work to do on RPC-over-RDMA.
>
> The main blocker before was support for bi-directional RPC, which all
> minorversions of NFSv4 use after mv 1, and that should be working as well
> as it does for NFSv4.1.
>
> NFSv4.2 itself should work, but I might choose to stay with NFSv4.1 for
> now if it were up to me, unless you have need of one of the new features.
> For example, there is no standard specification describing how READ_PLUS
> is supposed to work on RPC-over-RDMA (that's in the works).
>
>
> --
> Chuck Lever
>
>
>
> On Aug 19, 2016, at 1:06 AM, james harvey <[email protected]> wrote:
>
> Full sparse support would be nice, but certainly not critical. I'd
> rather stay with what was considered least problematic.
>
> I'm re-examining any workarounds we use, to see if any of the issues
> have been resolved so any workarounds are no longer needed. As a
> general rule, without a reason to do otherwise, I like letting
> something run with defaults (where it would pick 4.2) rather than
> overriding something.
>
> So, with RDMA on 4.7.1+, no reason to stay on NFSv4.0 instead of NFSv4.1?
NFSv4.1/RDMA should work in v4.7.
I'm still working on complete feature parity between TCP and RDMA,
and that includes NFSv4.2. I don't know of any specific NFSv4.2
feature that is not working, but it's not been as thoroughly
tested as NFSv4.[01].
> On Thu, Aug 18, 2016 at 11:26 AM, Chuck Lever <[email protected]> wrote:
>> Hi James-
>>
>>
>>> On Aug 18, 2016, at 12:09 AM, james harvey <[email protected]> wrote:
>>>
>>> A year ago, on 7/30/2015, Chuck Lever said NFS/RDMA wasn't yet working
>>> with NFSv4.1 and NFSv4.2, as a known issue.
>>>
>>> I was able to use "vers=4.0" to get around the issue.
>>>
>>> I see v4.2 seems to mount properly, but before switching over to it, I
>>> wanted to see if it's considered stable, or still to be avoided.
>>
>> Can you tell why you'd like to use it? Which NFSv4.2 feature is interesting
>> to you?
>>
>> I don't test it regularly, simply because
>>
>> - The complete tests on each version take a long time to run
>>
>> - NFSv4.2 features are all optional, and the Linux NFSv4.2 implementation
>> adds only a couple that probably won't be affected by RDMA. READ_PLUS will
>> need some attention at some point, but I think Anna is still polishing the
>> upper layer implementation.
>>
>> - I don't have any specific tests for security labels, which add to the
>> size of the NFSv4 GETATTR receive buffer whether labels are actually
>> retrieved or not. So there is a little NFSv4.2 testing we get for free just
>> by using NFSv4.0.
>>
>> - There's yet a lot of non-version-specific work to do on RPC-over-RDMA.
>>
>> The main blocker before was support for bi-directional RPC, which all
>> minorversions of NFSv4 use after mv 1, and that should be working as well
>> as it does for NFSv4.1.
>>
>> NFSv4.2 itself should work, but I might choose to stay with NFSv4.1 for
>> now if it were up to me, unless you have need of one of the new features.
>> For example, there is no standard specification describing how READ_PLUS
>> is supposed to work on RPC-over-RDMA (that's in the works).
>>
>>
>> --
>> Chuck Lever
>>
>>
>>
--
Chuck Lever