Change in ...nfs-ganesha[next]: Coverity: check if data->session is NULL after deref
by Zhu Shangzhong (GerritHub)
Zhu Shangzhong has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464535 )
Change subject: Coverity: check if data->session is NULL after deref
......................................................................
Coverity: check if data->session is NULL after deref
In nfs4_op_reclaim_complete, the pointer data->session has been
dereferenced in the statement "nfs_client_id_t
*clientid = data->session->clientid_record;" at the beginning. The "if"
condition "if (data->session == NULL)" is no effect. So the "if"
condition may be removed.
Change-Id: Ia3d62cc8957aca9e006fa954619126639cdda9fa
Signed-off-by: Shangzhong Zhu <zhu.shangzhong(a)zte.com.cn>
---
M src/Protocols/NFS/nfs4_op_reclaim_complete.c
1 file changed, 0 insertions(+), 5 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/35/464535/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464535
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: Ia3d62cc8957aca9e006fa954619126639cdda9fa
Gerrit-Change-Number: 464535
Gerrit-PatchSet: 1
Gerrit-Owner: Zhu Shangzhong <zhu.shangzhong(a)zte.com.cn>
Gerrit-MessageType: newchange
5 years, 4 months
Change in ...nfs-ganesha[next]: Coverity: Dereferencing a pointer that might be NULL
by Zhu Shangzhong (GerritHub)
Zhu Shangzhong has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464530 )
Change subject: Coverity: Dereferencing a pointer that might be NULL
......................................................................
Coverity: Dereferencing a pointer that might be NULL
In nfs4_acls_test(), the NULL might be returned from nfs4_acl_new_entry.
Change-Id: Iefd9b909ad7172b210bba3668f8e63ee0a18c9cf
Signed-off-by: Shangzhong Zhu <zhu.shangzhong(a)zte.com.cn>
---
M src/support/nfs4_acls.c
1 file changed, 16 insertions(+), 4 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/30/464530/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464530
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: Iefd9b909ad7172b210bba3668f8e63ee0a18c9cf
Gerrit-Change-Number: 464530
Gerrit-PatchSet: 1
Gerrit-Owner: Zhu Shangzhong <zhu.shangzhong(a)zte.com.cn>
Gerrit-MessageType: newchange
5 years, 4 months
Change in ...nfs-ganesha[next]: Coverity: dead code in fsal_create
by Zhu Shangzhong (GerritHub)
Zhu Shangzhong has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464474 )
Change subject: Coverity: dead code in fsal_create
......................................................................
Coverity: dead code in fsal_create
A if statement checks at the beginning of the fsal_create to see whether
the enumeration 'type' is 1~7(REGULAR_FILE~DIRECTORY). In the switch
statement, the NO_FILE_TYPE is 0, and EXTENDED_ATTR is 8. So the dead
code should be removed from the switch statement.
Change-Id: If8b2153072134dc5738fd56980bbacf6533336cd
Signed-off-by: Shangzhong Zhu <zhu.shangzhong(a)zte.com.cn>
---
M src/FSAL/fsal_helper.c
1 file changed, 0 insertions(+), 9 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/74/464474/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464474
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: If8b2153072134dc5738fd56980bbacf6533336cd
Gerrit-Change-Number: 464474
Gerrit-PatchSet: 1
Gerrit-Owner: Zhu Shangzhong <zhu.shangzhong(a)zte.com.cn>
Gerrit-MessageType: newchange
5 years, 4 months
回复:[NFS-Ganesha-Devel]_回复:Re:_nfs-ganesha_not_load_private_Moudle
by QR
Do you have following lines in main.c of your FSAL?const char XXfsal_name[] = "NCDFS";struct config_block XX_param = { .dbus_interface_name = "org.ganesha.nfsd.config.fsal.ncdfs", .blk_desc.name = "NCDFS",
--------------------------------
----- 原始邮件 -----
发件人:kjl8401 <kjl8401(a)126.com>
收件人:dang(a)fprintf.net
抄送人:devel(a)lists.nfs-ganesha.org
主题:[NFS-Ganesha-Devel]_回复:Re:_nfs-ganesha_not_load_private_Moudle
日期:2019年08月05日 19点46分
dear devel
Very sorry to trouble you!I think I have checked it according to you, but I still don't know the cause of the problem。I feel very depressed because of having wasted several days on this issue。I changed the name of module from NCSF to NCDFS。Please tell me where my mistake is and thank you very much!
ganesha.conf
The log of problem are the same as before!I am looking forward to hearing from you. Thank you very much!
At 2019-08-02 23:38:34, "Daniel Gryniewicz" <dang(a)fprintf.net> wrote:
You will generally get a faster response by posting to the mailing list (devel(a)lists.nfs-ganesha.org) than by mailing contributors directly.
FSALs are loaded by the fsal_manager in fsal_load.c. The library that is loaded is <libdir>/ganesha/lib<fsal>.so where <fsal> is the Name given in the config for that FSAL, transformed to lower case. You will need to make sure there are 3 things done correctly:1. The name of your fsal library must match the name given in the config2. Your fsal must be installed in the correct location3. Your fsal must have MODULE_INIT and MODULE_FINI functions built into it.
Without seeing the source, it's a bit hard to debug.
Daniel
On Fri, Aug 2, 2019 at 7:41 AM kjl8401 <kjl8401(a)126.com> wrote:
dear dang,hello, i have a question for you about using nfs-ganesha.The private moudle NCSF do not load while compiled. you are an important contributior of this project. I think you might meet this problem and hope you can reply to me. Let me tell you about question.
the private NCSF moudle looks like load successfully
/FSAL/FSAL_NCSF/CMakeList.txtlibfsalncsf.so generated successfully
but execute the command# ganesha.nfsd -f /etc/ganesha/ganesha.conf -L nfs-ganesha.log -N NIV_DEBUG
nfs-ganesha.log has not logi do not konow what causes this problem and how to resolve.I am looking forward to hearing from you. Thank you very much. Best, Sincerely,kjl8401
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
5 years, 4 months
Change in ...nfs-ganesha[next]: Kerberos Keytab file path should be configurable
by Trishali Nayar (GerritHub)
Trishali Nayar has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464391 )
Change subject: Kerberos Keytab file path should be configurable
......................................................................
Kerberos Keytab file path should be configurable
The hardcoded value of "/etc/krb5.keytab" is being used for the
keytab file. It should be configurable as part of the "NFS_KRB5"
stanzas "KeytabPath" value.
Change-Id: Ib786f550cc60be0a0eb78ea02b072f37b11998fd
Signed-off-by: Trishali Nayar <ntrishal(a)in.ibm.com>
---
M src/RPCAL/gss_credcache.c
1 file changed, 7 insertions(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/91/464391/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464391
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: Ib786f550cc60be0a0eb78ea02b072f37b11998fd
Gerrit-Change-Number: 464391
Gerrit-PatchSet: 1
Gerrit-Owner: Trishali Nayar <ntrishal(a)in.ibm.com>
Gerrit-MessageType: newchange
5 years, 4 months
Change in ...nfs-ganesha[next]: Copy/paste error in state_nlm_share
by Zhu Shangzhong (GerritHub)
Zhu Shangzhong has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464386 )
Change subject: Copy/paste error in state_nlm_share
......................................................................
Copy/paste error in state_nlm_share
Currently, the variable share_access is being used to compare with
OPEN4_SHARE_DENY_ALL. The share_access should be replaced with
share_deny.
Change-Id: If8a423b725ee8a70e9f56338367b8d101c8e5ec4
Signed-off-by: Shangzhong Zhu <zhu.shangzhong(a)zte.com.cn>
---
M src/SAL/state_share.c
1 file changed, 2 insertions(+), 2 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/86/464386/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/464386
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: If8a423b725ee8a70e9f56338367b8d101c8e5ec4
Gerrit-Change-Number: 464386
Gerrit-PatchSet: 1
Gerrit-Owner: Zhu Shangzhong <zhu.shangzhong(a)zte.com.cn>
Gerrit-MessageType: newchange
5 years, 4 months
FD hard limit exceeded
by Gin Tan
We are trying to figure out the hard limit for the FD, does nfs ganesha
impose a limit?
At the moment we are seeing these errors:
25/07/2019 19:27:59 : epoch 5d393d8c : nas2 : ganesha.nfsd-1681[cache_lru]
lru_run :INODE LRU :WARN :Futility count exceeded. Client load is opening
FDs faster than the LRU thread can close them.
25/07/2019 19:28:16 : epoch 5d393d8c : nas2 : ganesha.nfsd-1681[cache_lru]
lru_run :INODE LRU :WARN :Futility count exceeded. Client load is opening
FDs faster than the LRU thread can close them.
25/07/2019 19:28:34 : epoch 5d393d8c : nas2 : ganesha.nfsd-1681[svc_54]
mdcache_lru_fds_available :INODE LRU :CRIT :FD Hard Limit Exceeded, waking
LRU thread.
25/07/2019 19:29:02 : epoch 5d393d8c : nas : ganesha.nfsd-1681[svc_64]
mdcache_lru_fds_available :INODE LRU :CRIT :FD Hard Limit Exceeded, waking
LRU thread.
The system limit:
$ cat /proc/sys/fs/nr_open
2097152
And the limit for nfs-ganesha process:
$ cat /proc/1681/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 385977 385977
processes
Max open files 2097152 2097152 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 385977 385977 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
And the number of open files is
# ls /proc/1681/fd | wc -w
12739
I don't see why we are hitting the FD limit as we only have 12739 FD count.
It is impacting the NFS clients right now, file creation is fine but can't
open an existing file to write.
I'm using VFS FSAL, and the software versions are:
nfs-ganesha-2.7.5-1.el7.x86_64
nfs-ganesha-vfs-2.7.5-1.el7.x86_64
Thanks.
Gin
5 years, 4 months