Re: pNFS related commit a48cfbd5f9cfdf259136e0cf1f4bfc134ce8b8d8
by Assaf Yaari
In
https://www.rfc-editor.org/rfc/rfc8881.html#name-client-id-and-session-consi
it is written:
In the case of a server with concurrent pNFS roles that are served by a
> common client ID, if the EXCHANGE_ID request from the client has zero or a
> combination of the bits set in eia_flags, the server result should set bits
> that represent the higher of the acceptable combination of the server
> roles, with a preference to match the roles requested by the client. Thus,
> if a client request has (EXCHGID4_FLAG_USE_NON_PNFS |
> EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_PNFS_DS) flags set, and the
> server is both a metadata server and a data server, serving both the roles
> by a common client ID, the server SHOULD return with
> (EXCHGID4_FLAG_USE_PNFS_MDS | EXCHGID4_FLAG_USE_PNFS_DS) set.
> In the case of a server that has multiple concurrent pNFS roles, each role
> served by a unique client ID, if the client specifies zero or a combination
> of roles in the request, the server results SHOULD return *only one of
> the roles from the combination specified by the client request.* If the
> role specified by the server result does not match the intended use by the
> client, the client should send the EXCHANGE_ID specifying just the
> interested pNFS role.
<https://www.rfc-editor.org/rfc/rfc8881.html#section-13.1-7>
My understanding from that, is that if the client did specify a flag in the
eia_flags, then the server should match its capabilities to the requested
flag.
Yet, maybe someone else with more experience than me with pNFS can share
their POV. Frank?
P.s. my original change was just in order to pass compliance checks so if
the server does not have any pNFS capabilities then it must
return EXCHGID4_FLAG_USE_NON_PNFS. Before my change it returned 0 which
violated the spec.
I haven't really changed the original capabilities matching logic.
On Thu, Aug 15, 2024 at 12:11 AM Marc Eshel <eshel(a)us.ibm.com> wrote:
> I don’t think that we are violating the RFC but I think we can use better
> responses to the client.
>
> My servers do both MDS and DS so this what I see going back to the client
>
>
>
> 1. If eia_flags == 0
>
> server_pnfs_flags |= EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_PNFS_MDS
>
>
>
> 2. If eia_flags == EXCHGID4_FLAG_USE_PNFS_DS
>
> server_pnfs_flags |= EXCHGID4_FLAG_USE_PNFS_DS |
> *EXCHGID4_FLAG_USE_NON_PNFS*
>
>
>
> I would expect that for both we would return
>
> EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_PNFS_MDS
>
>
>
> Marc.
>
>
>
>
>
> *From: *Assaf Yaari <assafy(a)google.com>
> *Date: *Wednesday, August 14, 2024 at 2:46 AM
> *To: *Marc Eshel <eshel(a)us.ibm.com>
> *Cc: *Frank Stewart Filz <ffilz(a)ibm.com>, devel(a)lists.nfs-ganesha.org <
> devel(a)lists.nfs-ganesha.org>
> *Subject: *[EXTERNAL] Re: pNFS related commit
> a48cfbd5f9cfdf259136e0cf1f4bfc134ce8b8d8
>
> Hi Marc, The case that the client did sent pNFS flag is covered by the
> 'else' of this condition: } /* If client did ask for pNFS related server
> roles than try to match the server roles to the client request. */ else {
> if ((arg_EXCHANGE_ID4->eia_flags
>
> Hi Marc,
>
>
>
> The case that the client did sent pNFS flag is covered by the 'else' of
> this condition:
>
> }
> /* If client did ask for pNFS related server roles than try to match the
> server roles to the client request. */
> else {
> if ((arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_USE_PNFS_MDS)
> && (nfs_param.nfsv4_param.pnfs_mds))
> server_pnfs_flags |= EXCHGID4_FLAG_USE_PNFS_MDS;
> else
> server_pnfs_flags |= EXCHGID4_FLAG_USE_NON_PNFS;
> if ((arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_USE_PNFS_DS)
> && (nfs_param.nfsv4_param.pnfs_ds))
> server_pnfs_flags |= EXCHGID4_FLAG_USE_PNFS_DS;
> }
>
>
>
> I believe that the above conforms to RFC 8881 section 13.1.
>
> The first block section that you refer to, covers the case when the client
> doesn't send any pNFS flags so you should not modify the condition.
>
>
>
> Regarding the other issue that you wrote - pNFS is NFSv4.1(2) specific so
> it seems to me reasonable that it will be in the NFSv4 config block.
>
> Are you saying that you want the freedom to configure the pNFS abilities
> per share?
>
>
>
> As our product doesn't support pNFS I don't have strong thoughts about
> that. I advise that you continue this discussion with Frank.
>
>
>
> Regards,
>
> Assaf Y.
>
>
>
> On Wed, Aug 14, 2024 at 6:26 AM Marc Eshel <eshel(a)us.ibm.com> wrote:
>
> Hi Assf,
>
> I believe that we need the following change in the code that you changed
> last year. I am starting to test pNFS and if the client has any flags on in
> the pNFS mask we should check the clients request.
>
>
>
> diff --git a/src/Protocols/NFS/nfs4_op_exchange_id.c
> b/src/Protocols/NFS/nfs4_op_exchange_id.c
>
> index 15bb386fe..a6b730308 100644
>
> --- a/src/Protocols/NFS/nfs4_op_exchange_id.c
>
> +++ b/src/Protocols/NFS/nfs4_op_exchange_id.c
>
> @@ -172,7 +172,7 @@ enum nfs_req_result nfs4_op_exchange_id(struct
> nfs_argop4 *op,
>
>
>
> /* If client did not ask for pNFS related server roles than just
> set
>
> server roles */
>
> - if ((arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_MASK_PNFS) == 0) {
>
> + if (arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_MASK_PNFS) {
>
> if (nfs_param.nfsv4_param.pnfs_mds)
>
> server_pnfs_flags |= EXCHGID4_FLAG_USE_PNFS_MDS;
>
> else
>
>
>
> On another issue if you are familiar with pNFS code, it is checking the
> pNFS flags only in the NFSv4 block
>
> I think it should be at the EXPORT block.
>
>
>
> NFSv4
>
> {
>
> PNFS_MDS = true;
>
> PNFS_DS = true;
>
> }
>
>
>
> Thanks, Marc.
>
>
>
>
> --
>
>
>
> [image: Image removed by sender.]
>
> *Assaf Yaari*
>
> assafy(a)google.com
>
> SWE
>
> +972-54-2444-360
>
>
>
--
*Assaf Yaari*
assafy(a)google.com
SWE
+972-54-2444-360
8 months, 3 weeks
Re: pNFS related commit a48cfbd5f9cfdf259136e0cf1f4bfc134ce8b8d8
by Assaf Yaari
Hi Marc,
The case that the client did sent pNFS flag is covered by the 'else' of
this condition:
}
/* If client did ask for pNFS related server roles than try to match the
server roles to the client request. */
else {
if ((arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_USE_PNFS_MDS)
&& (nfs_param.nfsv4_param.pnfs_mds))
server_pnfs_flags |= EXCHGID4_FLAG_USE_PNFS_MDS;
else
server_pnfs_flags |= EXCHGID4_FLAG_USE_NON_PNFS;
if ((arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_USE_PNFS_DS)
&& (nfs_param.nfsv4_param.pnfs_ds))
server_pnfs_flags |= EXCHGID4_FLAG_USE_PNFS_DS;
}
I believe that the above conforms to RFC 8881 section 13.1.
The first block section that you refer to, covers the case when the client
doesn't send any pNFS flags so you should not modify the condition.
Regarding the other issue that you wrote - pNFS is NFSv4.1(2) specific so
it seems to me reasonable that it will be in the NFSv4 config block.
Are you saying that you want the freedom to configure the pNFS abilities
per share?
As our product doesn't support pNFS I don't have strong thoughts about
that. I advise that you continue this discussion with Frank.
Regards,
Assaf Y.
On Wed, Aug 14, 2024 at 6:26 AM Marc Eshel <eshel(a)us.ibm.com> wrote:
> Hi Assf,
>
> I believe that we need the following change in the code that you changed
> last year. I am starting to test pNFS and if the client has any flags on in
> the pNFS mask we should check the clients request.
>
>
>
> diff --git a/src/Protocols/NFS/nfs4_op_exchange_id.c
> b/src/Protocols/NFS/nfs4_op_exchange_id.c
>
> index 15bb386fe..a6b730308 100644
>
> --- a/src/Protocols/NFS/nfs4_op_exchange_id.c
>
> +++ b/src/Protocols/NFS/nfs4_op_exchange_id.c
>
> @@ -172,7 +172,7 @@ enum nfs_req_result nfs4_op_exchange_id(struct
> nfs_argop4 *op,
>
>
>
> /* If client did not ask for pNFS related server roles than just
> set
>
> server roles */
>
> - if ((arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_MASK_PNFS) == 0) {
>
> + if (arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_MASK_PNFS) {
>
> if (nfs_param.nfsv4_param.pnfs_mds)
>
> server_pnfs_flags |= EXCHGID4_FLAG_USE_PNFS_MDS;
>
> else
>
>
>
> On another issue if you are familiar with pNFS code, it is checking the
> pNFS flags only in the NFSv4 block
>
> I think it should be at the EXPORT block.
>
>
>
> NFSv4
>
> {
>
> PNFS_MDS = true;
>
> PNFS_DS = true;
>
> }
>
>
>
> Thanks, Marc.
>
--
*Assaf Yaari*
assafy(a)google.com
SWE
+972-54-2444-360
8 months, 4 weeks
[S] Change in ...nfs-ganesha[next]: SAL/nfs4_recovery.c: fix the issue where adding export fails when the...
by Zheng Zeng (GerritHub)
Zheng Zeng has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1199506?usp=email )
Change subject: SAL/nfs4_recovery.c: fix the issue where adding export fails when the gethostname function call fails
......................................................................
SAL/nfs4_recovery.c: fix the issue where adding export fails when the gethostname function call fails
Assuming the value of "sysconf(_SC_HOST_NAME_MAX)" is len.
When the actual length of the hostname exceeds (len - 1), calling
the gethostname function will result in an error, which can cause
the operation of adding new export to fail.
This patch allocates 256 bytes of space by default to store the hostname.
If the length of the hostname exceeds len, it takes the first len characters.
Otherwise, it uses the hostname directly.
Change-Id: Idc2955e72a484db1d078ab4b6b2d070ab2857e89
Signed-off-by: izxl007 <zengzheng007(a)163.com>
---
M src/SAL/nfs4_recovery.c
1 file changed, 14 insertions(+), 6 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/06/1199506/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1199506?usp=email
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email
Gerrit-MessageType: newchange
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: Idc2955e72a484db1d078ab4b6b2d070ab2857e89
Gerrit-Change-Number: 1199506
Gerrit-PatchSet: 1
Gerrit-Owner: Zheng Zeng <zengzheng007(a)163.com>
8 months, 4 weeks
pNFS related commit a48cfbd5f9cfdf259136e0cf1f4bfc134ce8b8d8
by Marc Eshel
Hi Assf,
I believe that we need the following change in the code that you changed last year. I am starting to test pNFS and if the client has any flags on in the pNFS mask we should check the clients request.
diff --git a/src/Protocols/NFS/nfs4_op_exchange_id.c b/src/Protocols/NFS/nfs4_op_exchange_id.c
index 15bb386fe..a6b730308 100644
--- a/src/Protocols/NFS/nfs4_op_exchange_id.c
+++ b/src/Protocols/NFS/nfs4_op_exchange_id.c
@@ -172,7 +172,7 @@ enum nfs_req_result nfs4_op_exchange_id(struct nfs_argop4 *op,
/* If client did not ask for pNFS related server roles than just set
server roles */
- if ((arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_MASK_PNFS) == 0) {
+ if (arg_EXCHANGE_ID4->eia_flags & EXCHGID4_FLAG_MASK_PNFS) {
if (nfs_param.nfsv4_param.pnfs_mds)
server_pnfs_flags |= EXCHGID4_FLAG_USE_PNFS_MDS;
else
On another issue if you are familiar with pNFS code, it is checking the pNFS flags only in the NFSv4 block
I think it should be at the EXPORT block.
NFSv4
{
PNFS_MDS = true;
PNFS_DS = true;
}
Thanks, Marc.
8 months, 4 weeks
[S] Change in ...nfs-ganesha[next]: nfs_rpc_dispatcher_thread: Move connection manager start from connect...
by Name of user not set (GerritHub)
mivry(a)google.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1199342?usp=email )
Change subject: nfs_rpc_dispatcher_thread: Move connection manager start from connection establishment.
......................................................................
nfs_rpc_dispatcher_thread: Move connection manager start from connection establishment.
Connection manager start is now made in the cb function that is called when
the first request has been received at the connection (whether haproxy
packet arrived or not) and the remote address is finally determined.
Change-Id: I2f5bb6d452935a461376e68b10291c00bdf8ed09
Signed-off-by: Miki Ivry <mivry(a)google.com>
---
M src/MainNFSD/nfs_rpc_dispatcher_thread.c
1 file changed, 26 insertions(+), 4 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/42/1199342/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1199342?usp=email
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email
Gerrit-MessageType: newchange
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: I2f5bb6d452935a461376e68b10291c00bdf8ed09
Gerrit-Change-Number: 1199342
Gerrit-PatchSet: 1
Gerrit-Owner: mivry(a)google.com
9 months
[M] Change in ...nfs-ganesha[next]: connection_manager: Add connection_manager__connection_init
by Name of user not set (GerritHub)
mivry(a)google.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1199341?usp=email )
Change subject: connection_manager: Add connection_manager__connection_init
......................................................................
connection_manager: Add connection_manager__connection_init
Function should be called at connection establishment.
Move initialization basic connection_manager struct members from
connection_manager__connection_started to this function.
Change-Id: Ia64aa52ec9286b2972d937c17aa0103c3702b8cd
Signed-off-by: Miki Ivry <mivry(a)google.com>
---
M src/MainNFSD/nfs_rpc_dispatcher_thread.c
M src/RPCAL/connection_manager.c
M src/include/connection_manager.h
3 files changed, 45 insertions(+), 8 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/41/1199341/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1199341?usp=email
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email
Gerrit-MessageType: newchange
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Change-Id: Ia64aa52ec9286b2972d937c17aa0103c3702b8cd
Gerrit-Change-Number: 1199341
Gerrit-PatchSet: 1
Gerrit-Owner: mivry(a)google.com
9 months
These plans help with the preliminary decision-making procedure for any type of site designe
by 8pq6vqad＠mediaholy.com
https://www.getdailyblogging.com
earch Engine Optimization, i.e. seo, refers to the whole procedure of using strategies that aid make changes in your web site material to make it rank high in regards to web traffic online. It assists in enhancing the visibility of the site on the internet. Search Engine Optimization plans, on the other hand, are the pre-picked combination of devices as well as offerings supplied to the individuals for their internet sites. These consist of various tools that aid in boosting the position of a specific web site. SEO business include websites, submissions, backlinks, SMO (social media optimization), web content optimization, E-commerce SEO, article, authority article, on-page SEO, technical SEO, off-page SEO, and so on. They additionally have numerous sorts of SEO plans like the fundamental SEO package, neighborhood SEO bundle, nationwide SEO bundle, SEO audit plan, etc. These plans help with the preliminary decision-making procedure for any type of site designer.
9 months
These plans help with the preliminary decision-making procedure for any type of site designer.
by 8pq6vqad＠mediaholy.com
[url=https://www.getdailyblogging.com/voipphone]voip phone system[/url]
earch Engine Optimization, i.e. seo, refers to the whole procedure of using strategies that aid make changes in your web site material to make it rank high in regards to web traffic online. It assists in enhancing the visibility of the site on the internet. Search Engine Optimization plans, on the other hand, are the pre-picked combination of devices as well as offerings supplied to the individuals for their internet sites. These consist of various tools that aid in boosting the position of a specific web site. SEO business include websites, submissions, backlinks, SMO (social media optimization), web content optimization, E-commerce SEO, article, authority article, on-page SEO, technical SEO, off-page SEO, and so on. They additionally have numerous sorts of SEO plans like the fundamental SEO package, neighborhood SEO bundle, nationwide SEO bundle, SEO audit plan, etc. These plans help with the preliminary decision-making procedure for any type of site designer.
9 months
