August 2023 - Devel - NFS Ganesha List Archives

Change in ...nfs-ganesha[next]: Allow EXPORT pseudo path to be changed during export update
by Frank Filz (GerritHub) 20 Feb '24

20 Feb '24

Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/490334 ) Change subject: Allow EXPORT pseudo path to be changed during export update ...................................................................... Allow EXPORT pseudo path to be changed during export update This also fully allows adding or removing NFSv4 support from an export since we can now handle the PseudoFS swizzing that occurs. Note that an explicit PseudoFS export may be removed or added, though you can not change it from export_id 0 because we currently don't allow changing the export_id. Note that this patch doesn't handle DBUS add or remove export though that is an option to improve. I may add them to this patch (it wouldn't be that hard) but I want to get this reviewed as is right now. There are implications to a client of changing the PseudoFS. I have tested moving an export in the PseudoFS with a client mounted. The client will be able to continue accessing the export, though it may see an ESTALE error if it navigates out of the export. The current working directory will go bad and the pwd comment will fail indicating a disconnected mount. I have also seen referencing .. from the root of the export wrapping around back to the root (I believe this is how disconnected mounts are set up). FSAL_PSEUDO lookups and create handles (PUTFH or any use of an NFSv3 handle where the inode isn't cached) which fail during an export update are instead turned into ERR_FSAL_DELAY which turns into NFS4ERR_DELAY or NFS3ERR_JUKEBOX to force the client to retry under the completed update. Change-Id: I507dc17a651936936de82303ff1291677ce136be Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> --- M src/FSAL/FSAL_PSEUDO/handle.c M src/MainNFSD/libganesha_nfsd.ver M src/Protocols/NFS/nfs4_pseudo.c M src/include/export_mgr.h M src/include/nfs_proto_functions.h M src/support/export_mgr.c M src/support/exports.c 7 files changed, 560 insertions(+), 203 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/34/490334/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/490334 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I507dc17a651936936de82303ff1291677ce136be Gerrit-Change-Number: 490334 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com> Gerrit-MessageType: newchange

2 2

Help needed on FD
by Alok Sinha 31 Jan '24

31 Jan '24

FD created at below path does not have correct link in /proc/self/fd. With vfs_readlink_by_handle , I can get a relative path but cannot get the absolute path of the FD. I need a suggestion for one of the below to get around a production bug: - How to get the full path of the FD? - How to get the parent vfs_fsal_obj_handle? - Anyway to bypass this flow by changing any config file? #0 vfs_create_handle (exp_hdl=0x55801aca22c0, hdl_desc=0x7f93889b1600, handle=0x7f93889b13f8, attrs_out=0x7f93889b1430) at /home/alok/pub/splfs-cache-2.8.3/src/FSAL/FSAL_VFS/handle.c:2020 #1 0x00007f94a1f0e13b in mdcache_locate_host (fh_desc=0x7f93889b1600, export=0x55801aca1f20, entry=0x7f93889b1578, attrs_out=0x0) at /home/alok/pub/splfs-cache-2.8.3/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:1109 #2 0x00007f94a1f02455 in mdcache_create_handle (exp_hdl=0x55801aca1f20, fh_desc=0x7f93889b1600, handle=0x7f93889b15d8, attrs_out=0x0) at /home/alok/pub/splfs-cache-2.8.3/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1613 #3 0x00007f94a1ec5ead in nfs4_mds_putfh (data=0x7f93201119e0) at /home/alok/pub/splfs-cache-2.8.3/src/Protocols/NFS/nfs4_op_putfh.c:211 #4 0x00007f94a1ec60d3 in nfs4_op_putfh (op=0x7f93201186d0, data=0x7f93201119e0, resp=0x7f932010ab20) at /home/alok/pub/splfs-cache-2.8.3/src/Protocols/NFS/nfs4_op_putfh.c:281 #5 0x00007f94a1ea96ae in process_one_op (data=0x7f93201119e0, status=0x7f93889b1b48) at /home/alok/pub/splfs-cache-2.8.3/src/Protocols/NFS/nfs4_Compound.c:920 #6 0x00007f94a1eaa8c5 in nfs4_Compound (arg=0x7f9320138d78, req=0x7f93201385a0, res=0x7f9320106840) at /home/alok/pub/splfs-cache-2.8.3/src/Protocols/NFS/nfs4_Compound.c:1329 #7 0x00007f94a1de8567 in nfs_rpc_process_request (reqdata=0x7f93201385a0) ---Type <return> to continue, or q <return> to quit--- at /home/alok/pub/splfs-cache-2.8.3/src/MainNFSD/nfs_worker_thread.c:1484 #8 0x00007f94a1de8854 in nfs_rpc_valid_NFS (req=0x7f93201385a0) at /home/alok/pub/splfs-cache-2.8.3/src/MainNFSD/nfs_worker_thread.c:1591 #9 0x00007f94a13b6faf in svc_vc_decode (req=0x7f93201385a0) at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/svc_vc.c:829 #10 0x00007f94a13b3225 in svc_request (xprt=0x7f9320000ce0, xdrs=0x7f9320066260) at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/svc_rqst.c:793 #11 0x00007f94a13b6ec0 in svc_vc_recv (xprt=0x7f9320000ce0) at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/svc_vc.c:802 #12 0x00007f94a13b31a5 in svc_rqst_xprt_task (wpe=0x7f9320000f00) at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/svc_rqst.c:774 #13 0x00007f94a13bcab0 in work_pool_thread (arg=0x7f9218003340) at /home/alok/pub/splfs-cache-2.8.3/src/libntirpc/src/work_pool.c:184 #14 0x00007f94a1badea5 in start_thread () from /lib64/libpthread.so.0 #15 0x00007f94a16ce9fd in clone () from /lib64/libc.so.6 -- Alok Sinha www.spillbox.io https://youtu.be/U-YupjLQ9bU

2 2

CONTRIBUTING_HOWTO.txt and some basic questions
by David Rieber 30 Aug '23

30 Aug '23

My team has been working with nfs-ganesha for some time. This week I started sending patches and paying more attention to CONTRIBUTING_HOWTO.txt First of all, the home page says the community maintains an active, open IRC channel on Libera #ganesha. Most of our developers keep in touch on this channel. I recently posted messages there but have not seen any replied (*). Is that channel actively used? It that the best way to ask questions? or is it this mailing list? Also, every time I connect to that IRC channel I get the message "NFS-Ganesha V5-dev.5 released! V4.4.1 is the current stable branch!". As I understand it, https://github.com/nfs-ganesha/nfs-ganesha/wiki/Release-Cycle#current-stabl… says V5.5 is the current stable release. The IRC message seems outdated and is causing confusion. And now a question about CONTRIBUTING_HOWTO.txt: It says "Establish from the other developers which branch of whose repository is the best to work in. Create an account on github.com, login and view that developers repository. Click "Fork" on the top right to create a copy of that repository. Let's say your name is "Paul Sheer" (replace "paul", "p_sheer" and "paulsheer" with your own name below), and say the developer who owns the repository is named Code Leader and his github.com login is "codeleader". Now let's say the code branch is "new-unstable-dev-project". Then it gives an example: "git clone https://github.com/codeleader/nfs-ganesha.git --branch new-branch ...... The current (as of 2019-02-07) branch for development is: git clone https://github.com/nfs-ganesha/nfs-ganesha.git --branch next". And the question is: Do I really need to clone from some developer's repository? (*) I hope I'm not coming across as super impatient. I just want to make sure I understand how to work with the nfs-ganesha community.

1 1

Re: CONTRIBUTING_HOWTO.txt and some basic questions
by Frank Filz 30 Aug '23

30 Aug '23

> Thank you for the response Frank. I don't see your responses on > https://lists.nfs-ganesha.org/archives/list/devel@lists.nfs-ganesha.org/thr… > Is that by design? Hmm, I did a reply all which usually gets the list cc:ed. You must have a reply-to header that overrode that? > Can you tell me more about the stability or rather instabilities you are aware of in V5.5? > I recently imported V5.5 into our project at Google. There are some known crashes: https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1167738?usp=search https://github.com/nfs-ganesha/nfs-ganesha/issues/989 https://github.com/nfs-ganesha/nfs-ganesha/issues/990 And I think there's another github issue or something, this week has turned out to be pretty busy so I'm still trying to sort everything out. Oh, there's also a FSAL_CEPH issue with 0 length reads... > Also, I am not in a position to bring CONTRIBUTING_HOWTO.txt up to date with > regards to cloning. It would be great for future readers if that documentation is improved. Please open a github issue and then it at least is in our backlog. Thanks Frank On Wed, Aug 30, 2023 at 10:57 AM Frank Filz <ffilzlnx(a)mindspring.com> wrote: > First of all, the home page says the community maintains an active, open IRC > channel on Libera #ganesha. Most of our developers keep in touch on this > channel. I recently posted messages there but have not seen any replied (*). Is > that channel actively used? It that the best way to ask questions? or is it this > mailing list? I should also point out that time zone differences can impact IRC responses. And this is a good reason to follow up with e-mail if you don't get a prompt answer. I can't tell you how many times someone in India has asked a question, and then by the time I'm logged on in the morning (Pacific Time Zone), they have logged off and I can't respond to them... I do try and leave myself logged onto IRC so I will at least see things, but that doesn't help if the person asking the question does not do the same. Frank

1 0

[S] Change in ...nfs-ganesha[next]: Added extern declaration of reread_config to nfs_lib.h
by Name of user not set (GerritHub) 30 Aug '23

30 Aug '23

drieber(a)google.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168210?usp=email ) Change subject: Added extern declaration of reread_config to nfs_lib.h ...................................................................... Added extern declaration of reread_config to nfs_lib.h This allows triggering config reload via a mechanism other than sighup (we are using this for dynamically setting ganesha's logging level). The boolean return value indicates if there were any problems during config reload. Change-Id: Id376c39c55a86d3fe326fa618c19c2b6cbf6cd56 Signed-off-by: David Rieber <drieber(a)google.com> --- M src/MainNFSD/nfs_init.c M src/include/nfs_lib.h 2 files changed, 13 insertions(+), 6 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/10/1168210/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168210?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Id376c39c55a86d3fe326fa618c19c2b6cbf6cd56 Gerrit-Change-Number: 1168210 Gerrit-PatchSet: 1 Gerrit-Owner: drieber(a)google.com Gerrit-MessageType: newchange

1 0

[S] Change in ...nfs-ganesha[next]: Handle Expired IP to Name mapping in cache
by Rojin George (GerritHub) 30 Aug '23

30 Aug '23

Rojin George has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168193?usp=email ) Change subject: Handle Expired IP to Name mapping in cache ...................................................................... Handle Expired IP to Name mapping in cache When a user was trying to mount client using NFS ganesha wildcard server config from a ubuntu client and this mount was failing. After debugging it was found, that the hostname to ip cache [ht_ip_name] was only updated once and the cache is set to never expire. So if the clientIP changes with DNS updated for example like in DHCP, then mount request would fail. This change avoids this, by validating the timestamp of the cache entry and marking it to be expired in the get path, if so. Thereby getting the new entry added to the cache. Change-Id: I24f30100028e667f38a7eccadb5cc17b2da9d7b0 Signed-off-by: Rojin George <itsmerojin(a)gmail.com> --- M src/support/nfs_ip_name.c 1 file changed, 19 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/93/1168193/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168193?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I24f30100028e667f38a7eccadb5cc17b2da9d7b0 Gerrit-Change-Number: 1168193 Gerrit-PatchSet: 1 Gerrit-Owner: Rojin George <itsmerojin(a)gmail.com> Gerrit-MessageType: newchange

1 0

[XS] Change in ...nfs-ganesha[next]: Update server stats to include NFS v4.3 operations.
by Bjorn Leffler (GerritHub) 29 Aug '23

29 Aug '23

Bjorn Leffler has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168188?usp=email ) Change subject: Update server stats to include NFS v4.3 operations. ...................................................................... Update server stats to include NFS v4.3 operations. Change-Id: I2ba0d7c9845607876b69b1be7f910ec141cd3929 Signed-off-by: Bjorn Leffler <leffler(a)google.com> --- M src/support/server_stats.c 1 file changed, 4 insertions(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/88/1168188/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168188?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I2ba0d7c9845607876b69b1be7f910ec141cd3929 Gerrit-Change-Number: 1168188 Gerrit-PatchSet: 1 Gerrit-Owner: Bjorn Leffler <leffler(a)google.com> Gerrit-MessageType: newchange

1 0

[M] Change in ...nfs-ganesha[next]: Moved enum recovery_backend and associated #define to solve forward d...
by Name of user not set (GerritHub) 29 Aug '23

29 Aug '23

drieber(a)google.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168185?usp=email ) Change subject: Moved enum recovery_backend and associated #define to solve forward declaration issue. ...................................................................... Moved enum recovery_backend and associated #define to solve forward declaration issue. When nfs-ganesha is compiled in our c++ project, we get an error due to the forward declaration of the recovery_backend enum. Those are supported in C but not in C++. Change-Id: I4955188d6f83b378af46ef376f84f414796fa708 Signed-off-by: David Rieber <drieber(a)google.com> --- M src/include/gsh_config.h A src/include/gsh_recovery.h M src/include/sal_functions.h 3 files changed, 43 insertions(+), 14 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/85/1168185/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168185?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I4955188d6f83b378af46ef376f84f414796fa708 Gerrit-Change-Number: 1168185 Gerrit-PatchSet: 1 Gerrit-Owner: drieber(a)google.com Gerrit-MessageType: newchange

1 0

[XS] Change in ...nfs-ganesha[next]: fs_lock is only defined when GSH_CAN_HOST_LOCAL_FS is #defined.
by Name of user not set (GerritHub) 29 Aug '23

29 Aug '23

drieber(a)google.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168184?usp=email ) Change subject: fs_lock is only defined when GSH_CAN_HOST_LOCAL_FS is #defined. ...................................................................... fs_lock is only defined when GSH_CAN_HOST_LOCAL_FS is #defined. Change-Id: I45178e27f431777efe348abecabae1ad45a73ada Signed-off-by: David Rieber <drieber(a)google.com> --- M src/FSAL/fsal_destroyer.c M src/FSAL/fsal_manager.c 2 files changed, 4 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/84/1168184/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168184?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I45178e27f431777efe348abecabae1ad45a73ada Gerrit-Change-Number: 1168184 Gerrit-PatchSet: 1 Gerrit-Owner: drieber(a)google.com Gerrit-MessageType: newchange

1 0

[XS] Change in ...nfs-ganesha[next]: In vfs_getattr2, initialize variables status and out_fd to fix uninit...
by Name of user not set (GerritHub) 29 Aug '23

29 Aug '23

drieber(a)google.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168163?usp=email ) Change subject: In vfs_getattr2, initialize variables status and out_fd to fix uninitialized use. ...................................................................... In vfs_getattr2, initialize variables status and out_fd to fix uninitialized use. Change-Id: Ic47f398d5da3e74803442a3dbbf4de28f4387e7f Signed-off-by: David Rieber <drieber(a)google.com> --- M src/FSAL/FSAL_VFS/file.c 1 file changed, 3 insertions(+), 2 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/63/1168163/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1168163?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Ic47f398d5da3e74803442a3dbbf4de28f4387e7f Gerrit-Change-Number: 1168163 Gerrit-PatchSet: 1 Gerrit-Owner: drieber(a)google.com Gerrit-MessageType: newchange

1 0