inconsistent nfs-ganesha error at startup (v2.8, CentOS 7)
by Todd Pfaff
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
4 years
questions about stability of nfs-ganesha versions and PROXY FSAL
by Todd Pfaff
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
4 years
ganesha nfs recovery on shared storage
by Grant Chesy
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
4 years
nfs-ganesha in a cluster with IP failover
by alxg＠weka.io
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
4 years
Unable to delete last ACE entry of an ACL on FSAL_VFS with ENABLE_VFS_DEBUG_ACL as ON
by subhash.arya＠seagate.com
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
4 years
