From: "Mkrtchyan, Tigran" <tigran.mkrtchyan@desy.de>
To: trondmy <trondmy@hammerspace.com>
Cc: linux-nfs <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v3 00/11] Add RDMA support to the pNFS file+flexfiles data channels
Date: Fri, 13 Nov 2020 13:48:07 +0100 (CET) [thread overview]
Message-ID: <1375056959.614278.1605271687151.JavaMail.zimbra@desy.de> (raw)
In-Reply-To: <3a3696f03eef74ac4723fdc0d1297076a34aa8ae.camel@hammerspace.com>
Hi Trond,
whit this changes (3ee69a14f92d74ced2647140b3799511ba4f3fa5) I see an infinite loop
of LAYOUTGET->GETDEVICEINFO->LAYOUTRETURN without any attempt to connect to a DS.
This is how the response to LAYOUTGET looks like.
Network File System, Ops(2): SEQUENCE GETDEVINFO
[Program Version: 4]
[V4 Procedure: COMPOUND (1)]
Status: NFS4_OK (0)
Tag: <EMPTY>
length: 0
contents: <EMPTY>
Operations (count: 2)
Opcode: SEQUENCE (53)
Opcode: GETDEVINFO (47)
Status: NFS4_OK (0)
layout type: LAYOUT4_FLEX_FILES (4)
r_netid: tcp
length: 3
contents: tcp
fill bytes: opaque data
r_addr: 131.169.191.143.125.49
length: 22
contents: 131.169.191.143.125.49
fill bytes: opaque data
version: 4
minorversion: 1
max_rsize: 1048576
max_wsize: 1048576
tightly coupled: Yes
notify_mask: 0x00000006 (Change, Delete)
notify_type: Change (1)
notify_type: Delete (2)
[Main Opcode: GETDEVINFO (47)]
The MDS is mounted with IPv4. I can provide the full packet trace, if needed.
Regards,
Tigran.
----- Original Message -----
> From: "trondmy" <trondmy@hammerspace.com>
> To: "linux-nfs" <linux-nfs@vger.kernel.org>
> Sent: Wednesday, 11 November, 2020 00:42:31
> Subject: Re: [PATCH v3 00/11] Add RDMA support to the pNFS file+flexfiles data channels
> On Tue, 2020-11-10 at 18:18 -0500, trondmy@kernel.org wrote:
>> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>>
>> Add support for connecting to the pNFS files/flexfiles data servers
>> through RDMA, assuming that the GETDEVICEINFO call advertises that
>> support.
>>
>> v2: Fix layoutstats encoding for pNFS/flexfiles.
>> v3: Move most of the netid handling into the SUNRPC and RDMA modules.
>> Fix up the mount code to benefit more from automated loading of
>> SUNRPC transport modules.
>>
>
> Note that one cleanup that I did not perform, but which really could be
> useful should we want to add more transport mechanisms, is to move the
> code to parse stringified addresses (in particular IETF style
> "universal addresses") into the transport modules so that the actual
> parsing of mount and pNFS transport info can be automatically extended
> when new transport modules are added.
>
> --
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2020-11-13 12:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 23:18 [PATCH v3 00/11] Add RDMA support to the pNFS file+flexfiles data channels trondmy
2020-11-10 23:18 ` [PATCH v3 01/11] SUNRPC: xprt_load_transport() needs to support the netid "rdma6" trondmy
2020-11-10 23:18 ` [PATCH v3 02/11] SUNRPC: Close a race with transport setup and module put trondmy
2020-11-10 23:18 ` [PATCH v3 03/11] SUNRPC: Add a helper to return the transport identifier given a netid trondmy
2020-11-10 23:18 ` [PATCH v3 04/11] NFS: Switch mount code to use xprt_find_transport_ident() trondmy
2020-11-10 23:19 ` [PATCH v3 05/11] SUNRPC: Remove unused function xprt_load_transport() trondmy
2020-11-10 23:19 ` [PATCH v3 06/11] NFSv4/pNFS: Use connections to a DS that are all of the same protocol family trondmy
2020-11-10 23:19 ` [PATCH v3 07/11] pNFS: Add helpers for allocation/free of struct nfs4_pnfs_ds_addr trondmy
2020-11-10 23:19 ` [PATCH v3 08/11] NFSv4/pNFS: Store the transport type in " trondmy
2020-11-10 23:19 ` [PATCH v3 09/11] pNFS/flexfiles: Fix up layoutstats reporting for non-TCP transports trondmy
2020-11-10 23:19 ` [PATCH v3 10/11] SUNRPC: Fix up open coded kmemdup_nul() trondmy
2020-11-10 23:19 ` [PATCH v3 11/11] pNFS: Clean up open coded xdr string decoding trondmy
2020-11-10 23:42 ` [PATCH v3 00/11] Add RDMA support to the pNFS file+flexfiles data channels Trond Myklebust
2020-11-13 12:48 ` Mkrtchyan, Tigran [this message]
2020-11-13 21:30 ` Mkrtchyan, Tigran
2020-11-13 22:45 ` Trond Myklebust
2020-11-13 23:46 ` Mkrtchyan, Tigran
2020-11-14 14:29 ` Trond Myklebust
2020-11-16 20:55 ` Mkrtchyan, Tigran
2020-11-17 14:50 ` Mkrtchyan, Tigran
2020-11-26 17:17 ` Mkrtchyan, Tigran
2020-12-01 10:59 ` Mkrtchyan, Tigran
2020-12-01 14:44 ` Mkrtchyan, Tigran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1375056959.614278.1605271687151.JavaMail.zimbra@desy.de \
--to=tigran.mkrtchyan@desy.de \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.