April 2020 - Support - NFS Ganesha List Archives

inconsistent nfs-ganesha error at startup (v2.8, CentOS 7)
by Todd Pfaff 09 Apr '20

09 Apr '20

I'm using nfs-ganesha 2.8 on CentOS 7. Inconsistently, I will get errors like this in ganesha.log at nfs-ganesha startup: 08/04/2020 22:25:26 : epoch 5e8e8796 : ganesha : ganesha.nfsd-1647[main] init_export_root :EXPORT :CRIT :Lookup failed on path, ExportId=20040 Path=/pool/export/a FSAL_ERROR=(Invalid object type,10063) This is using PROXY FSAL for a valid, functioning nfs export from another host X. I have other PROXY exports with different export IDs and different paths for this same host X that succeed during the same startup for which the error above is generated. I will see different exports IDs and paths in these errors for different startups, so it's not consistently always failing on one particular export ID. From one startup to another: - I may see this error about this same export, - I may see this error about some other export, - I may see no errors. Thoughts? Thanks, Todd

2 1

questions about stability of nfs-ganesha versions and PROXY FSAL
by Todd Pfaff 09 Apr '20

09 Apr '20

I'm having stability problems with nfs-ganesha 2.8 and PROXY FSAL on CentOS 7. I haven't yet tried nfs-ganesha 3.0 but I could probably quickly and easily move to that if there is an advantage in doing so. Before I spend time switching from 2.8 to 3.0, can anyone tell me whether either of these versions of nfs-ganesha is considered to be more stable than the other? centos-release-nfs-ganesha28.noarch : NFS-Ganesha 2.8 packages from the CentOS : Storage SIG repository centos-release-nfs-ganesha30.noarch : NFS-Ganesha 3.0 packages from the CentOS : Storage SIG repository What about PROXY FSAL in either of these versions - is one or the other known to be more stable? Is there a more robust version of nfs-ganesha and PROXY FSAL that I should consider trying instead? Thanks, Todd

2 1

ganesha nfs recovery on shared storage
by Grant Chesy 08 Apr '20

08 Apr '20

Hello, I want to setup an active-passive two node nfsv4 only cluster. Is it safe to have /var/lib/nfs/ganesha on shared storage with both instances of ganesha running but only one owning the sole VIP, so only one node is answering client requests / updating the recovery files? I.e., by safe, I mean the recovery files will not get corrupted / deleted by the other node? I see paths "node0" that suggest that a shared storage use case was considered. /var/lib/nfs/ganesha/v4old/node0 /var/lib/nfs/ganesha/v4recov/node0 But, I don't see anywhere in the man pages to indicate that an instance is e.g., node1. And, if there was, I would need a way to tell node1 to use node0's recovery files when node1 becomes master. If safe, my thought was to have a keepalived notify script run something like this when a node enters MASTER state. But, if there were separate node0 and node1 recovery file paths, I don't see how to tell nodeX to use nodeY's recovery files on failover initiated recovery: dbus-send --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/admin org.ganesha.nfsd.admin.grace string:5:${VIP} If the shared storage recovery bit is OK, is there anything I need to add to the nfs-ganesha config to make this work? And, does that dbus command look OK? I'm running nfs-ganesha version 2.7.1 packaged in Debian Buster. I have 2X working nfs-ganesha single node setups using gluster FSAL that I hope to turn into an nfs cluster. Regards

2 1

nfs-ganesha in a cluster with IP failover
by alxg＠weka.io 05 Apr '20

05 Apr '20

Hi, We'e setting up ganesha using FSAL_VFS, and NFSv3 only. We have a cluster of them running with floating IPs being failed over between them when a host dies. The question we have is regarding writes which are UNSTABLE - meaning the client writes out from its cache for example with UNSTABLE, and then sends a COMMIT. In the event of a ganesha host crashing after receiving the writeouts, but before the COMMIT - is it assured that when the floating IP will failover to another host the client will resend the unstable writes again as well? I guess this has several parts to it: * Client side - assuming it's a linux kernel nfs client and it uses the pagecache - does it mark the pages clean right after successfully sending their writes as unstable, or does it mark them as clean only after it successfully sends a COMMIT on them as well? Do you happen to know? * Server side - Does nfs-ganesha have some data cache? Or the writes being unstable just means they can land in the pagecache of the server side, and stay there until the COMMIT does a sync? in that case do we need to set `NFS_Commit = true`? What are the guidelines on such a setup to ensure data doesn't get lost and doesn't corrupt? Thank you, Alex

3 7

method to use client_mgr.c and server_stats.c in NFS Ganesha
by Suresh Kosuru 03 Apr '20

03 Apr '20

Hi, Can you point me help? how can I use client_mgr.c and server_stats.c in nfs ganesha and where will this info logging? Thanks Suresh

3 2

Unable to delete last ACE entry of an ACL on FSAL_VFS with ENABLE_VFS_DEBUG_ACL as ON
by subhash.arya＠seagate.com 01 Apr '20

01 Apr '20

Hello all, We are trying to use ACL functionality for FSAL_VFS and seeing the following issue while deleting the ACE entries. 1. Get/List file ACL -bash-4.2$ nfs4_getfacl abc # file: abc A::dev1:rxtTncy A::sub:rxtTncy 2. Delete specified ACE entry from the ACL and check -bash-4.2$ nfs4_setfacl -x A::dev1:RXT abc -bash-4.2$ nfs4_getfacl abc # file: abc A::sub:rxtTncy 3. Delete the last ACE bash-4.2$ nfs4_setfacl -x A::sub:RXT abc 4. Check if the last ACE is deleted and it's not. -bash-4.2$ nfs4_getfacl abc # file: abc A::sub:rxtTncy Inspite of deleting the last ACE, the nfs4_getfacl still shows the deleted ACE. Could anyone help and let us know if we are missing something here? Thanks, Subhash

3 2