August 2024 - Devel - NFS Ganesha List Archives

Re: pNFS related commit a48cfbd5f9cfdf259136e0cf1f4bfc134ce8b8d8
by Assaf Yaari 15 Aug '24

15 Aug '24

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

1 0

Re: pNFS related commit a48cfbd5f9cfdf259136e0cf1f4bfc134ce8b8d8
by Assaf Yaari 14 Aug '24

14 Aug '24

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

2 1

[S] Change in ...nfs-ganesha[next]: SAL/nfs4_recovery.c: fix the issue where adding export fails when the...
by Zheng Zeng (GerritHub) 14 Aug '24

14 Aug '24

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>

1 0

pNFS related commit a48cfbd5f9cfdf259136e0cf1f4bfc134ce8b8d8
by Marc Eshel 13 Aug '24

13 Aug '24

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.

1 0

[S] Change in ...nfs-ganesha[next]: nfs_rpc_dispatcher_thread: Move connection manager start from connect...
by Name of user not set (GerritHub) 12 Aug '24

12 Aug '24

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

1 0

[XS] Change in ...nfs-ganesha[next]: sal_functions.h: Increase size of DISPLAY_CLIENTID_SIZE to 37
by Name of user not set (GerritHub) 12 Aug '24

12 Aug '24

mivry(a)google.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1199343?usp=email ) Change subject: sal_functions.h: Increase size of DISPLAY_CLIENTID_SIZE to 37 ...................................................................... sal_functions.h: Increase size of DISPLAY_CLIENTID_SIZE to 37 This const is used display_clientid() for formatting client id. format string len('Unique=0x12345678 Counter=0x12345678') = 36, does not take into account null terminator. Change-Id: I89ca49c03da3b788c6d98b4900a16f87047e712f Signed-off-by: Miki Ivry <mivry(a)google.com> --- M src/include/sal_functions.h 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/43/1199343/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1199343?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: I89ca49c03da3b788c6d98b4900a16f87047e712f Gerrit-Change-Number: 1199343 Gerrit-PatchSet: 1 Gerrit-Owner: mivry(a)google.com

1 0

[M] Change in ...nfs-ganesha[next]: connection_manager: Add connection_manager__connection_init
by Name of user not set (GerritHub) 12 Aug '24

12 Aug '24

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

1 0

Updated invitation: Ganesha community call @ Weekly from 7am to 8am on Tuesday from Tue Jul 23 to Mon Aug 12 (PDT) (devel@lists.nfs-ganesha.org)
by Frank Filz 12 Aug '24

12 Aug '24

This event has been updated Changed: time Ganesha community call Weekly from 7am to 8am on Tuesday from Tuesday Jul 23 to Monday Aug 12 Pacific Time - Los Angeles Location IL-TLV-ELCO-43-6-Marshmallow (9) [GVC, Not Wheelchair Accessible] https://www.google.com/maps/search/IL-TLV-ELCO-43-6-Marshmallow+(9)+%5BGVC,… Join with Google Meet https://meet.google.com/mkh-ctnj-tqz?hs=224 Join by phone (US) +1 401-702-0462 PIN: 495972631 More joining options https://tel.meet/mkh-ctnj-tqz?pin=2844708468265&hs=0 Join using SIP 2844708468265(a)gmeet.redhat.com ID: 2844708468265 Organizer Frank Filz ffilz(a)redhat.com Guests Frank Filz - organizer thomas.vanderputten(a)panzura.com ffilzg(a)gmail.com Daniel Gryniewicz dmanzoni(a)verisign.com martin(a)uni-mainz.de Matt Benjamin Kaleb Keithley leffler(a)google.com sagar.it.iiests(a)gmail.com geva30(a)gmail.com assafy(a)google.com liorsu(a)google.com gauravin(a)google.com yashnarang(a)google.com dipit(a)google.com roopkamal(a)google.com RICHARD RUPP alok(a)spillbox.io punadikar.sachin(a)gmail.com ndevos(a)ibm.com sriram.patil(a)broadcom.com itsmerojin(a)gmail.com drieber(a)google.com Marc Eshel yonic(a)google.com shaharhoch(a)google.com Naresh Chillarege ofirvins(a)google.com mivry(a)google.com devel(a)lists.nfs-ganesha.org Wyll Ingersoll hu hansen ffilz(a)ibm.com Marcus Gorzellik Yogendra Charya Sriram Patil Jacobson, Erik blaine.gardner(a)ibm.com naresh.chillarege(a)ibm.com View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=NXZubmZhbGJwcTdi… Reply for devel(a)lists.nfs-ganesha.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=NXZubmZhbGJwcTdi… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 0

These plans help with the preliminary decision-making procedure for any type of site designe
by 8pq6vqad＠mediaholy.com 11 Aug '24

11 Aug '24

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.

1 0

These plans help with the preliminary decision-making procedure for any type of site designer.
by 8pq6vqad＠mediaholy.com 11 Aug '24

11 Aug '24

[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.

1 0