Change in ...nfs-ganesha[next]: Move nfs_init_stats_time outside USE_DBUS.
by Solomon Boulos (GerritHub)
Solomon Boulos has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502439 )
Change subject: Move nfs_init_stats_time outside USE_DBUS.
......................................................................
Move nfs_init_stats_time outside USE_DBUS.
d049c1e632e440 broke builds that don't have
USE_DBUS turned on (it's not compiled into
export_mgr.o otherwise).
Change-Id: Ie3ca0834b9af2c39ff77d984e7d5ead798d3a971
Signed-off-by: Solomon Boulos <boulos(a)google.com>
---
M src/support/export_mgr.c
1 file changed, 19 insertions(+), 15 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/39/502439/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502439
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: Ie3ca0834b9af2c39ff77d984e7d5ead798d3a971
Gerrit-Change-Number: 502439
Gerrit-PatchSet: 1
Gerrit-Owner: Solomon Boulos <boulos(a)google.com>
Gerrit-MessageType: newchange
4 years, 4 months
Change in ...nfs-ganesha[next]: Fix two clang build errors.
by Solomon Boulos (GerritHub)
Solomon Boulos has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502437 )
Change subject: Fix two clang build errors.
......................................................................
Fix two clang build errors.
clang's static analysis found two "bugs".
The first was an unsigned number (delegation count) was
being checked for being negative (the test should have been == 0).
The second was a gsh_refstr check that the byte array "pointer" was
non NULL. Since the byte array is inline though, the pointer is
always non-NULL (dereferencing the gsh_refstr itself, above, may crash
first).
Change-Id: Ie18344a965074f6b696ed95a652984c939c4a659
Signed-off-by: Solomon Boulos <boulos(a)google.com>
---
M src/Protocols/NFS/nfs4_pseudo.c
M src/SAL/state_deleg.c
2 files changed, 1 insertion(+), 2 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/37/502437/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502437
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: Ie18344a965074f6b696ed95a652984c939c4a659
Gerrit-Change-Number: 502437
Gerrit-PatchSet: 1
Gerrit-Owner: Solomon Boulos <boulos(a)google.com>
Gerrit-MessageType: newchange
4 years, 4 months
Questions about USE_FSAL_CEPH_ABORT_CONN
by liuwei
Hi,
I found many error info in the ganesha.log when stop nfs-ganesha.service, as follows.
ganesha.log:
：ganesha.nfsd-1550083[Admin] mdcache_lru_clean INODE:F_DBG:Trusting op_ctx export id 2
：ganesha.nfsd-1550083[Admin] posix2fsal_error:FSAL:CRIT:Default case mapping Transport endpoint is not connected (107) to ERR_FSAL_SERVERFAULT
：ganesha.nfsd-1550083[Admin]
mdcache_Iru_clean:INODE LRU:CRIT:Error closing file in cleanup:Undefined server error
My version info: Ganesha-3.3+FSAL_CEPH(ceph version 14.2.10)；
I went through the relevant code and still didn't understand the intention of the code.
static void release_export(struct gsh_export *export)
{
export->fsal_export->exp_ops.prepare_unexport(export->fsal_export)；
//mdcache_prepare_unexport
/* Release state belonging to this export */
state_release_export(export);
/* Flush FSAL-specific state */
export->fsal_export->exp_ops.unexport(export->fsal_export,obj);
//mdcache_unexport
}
The first thing to declare is that
USE_FSAL_CEPH_ABORT_CONN has been opened, so calling ceph_abort_conn() in ceph_prepare_unexport will abort the connection and umount.
However, the following operation will still need export->cmount and the connect, such as fsal_close() in
mdcache_Iru _clean().
I think that is the reason for the error printing. To sum up, I have two questions:
1、Isn't it reasonable to disconnect in
prepare_unexport before mdcache_lru_clean?
2、What is the intention of doing so? What will happen if I turn off USE_FSAL_CEPH_ABORT_CONN?
| |
liuwei_coder
|
|
邮箱：liuwei_coder(a)163.com
|
签名由 网易邮箱大师 定制
4 years, 4 months
Change in ...nfs-ganesha[next]: PROXY_V3: work around bindresvport threadsafety.
by Solomon Boulos (GerritHub)
Solomon Boulos has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502353 )
Change subject: PROXY_V3: work around bindresvport threadsafety.
......................................................................
PROXY_V3: work around bindresvport threadsafety.
To get a privileged port, the V3 proxy's rpc code
asks bindresvport_sa to hand us one. Modern versions
of glibc (since 2.17) are thread-safe, but many existing
implementations (including libntirpc) just use a local
static variable for the "choose a port". The V4 proxy
calls the related rresvport_af but is holding a lock,
so it's at least single threaded amongst itself.
The race here was causing the client port to sometimes be an
unprivileged port, so knfsd was correctly returning a
permission error.
Change-Id: I5a9f60451cf9154130a6f3fc21979cbe6e6d2049
Fixes: #580
Signed-off-by: Solomon Boulos <boulos(a)google.com>
---
M src/FSAL/FSAL_PROXY_V3/rpc.c
1 file changed, 30 insertions(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/53/502353/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502353
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: I5a9f60451cf9154130a6f3fc21979cbe6e6d2049
Gerrit-Change-Number: 502353
Gerrit-PatchSet: 1
Gerrit-Owner: Solomon Boulos <boulos(a)google.com>
Gerrit-MessageType: newchange
4 years, 4 months
lseek gets bad offset from nfs client with ganesha/gluster which supports SEEK
by Kinglong Mee
The latest ganesha/gluster supports seek according to,
https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-41#section-15.11
From the given sa_offset, find the next data_content4 of type sa_what
in the file. If the server can not find a corresponding sa_what,
then the status will still be NFS4_OK, but sr_eof would be TRUE. If
the server can find the sa_what, then the sr_offset is the start of
that content. If the sa_offset is beyond the end of the file, then
SEEK MUST return NFS4ERR_NXIO.
For a file's filemap as,
Part 1: HOLE 0x0000000000000000 ---> 0x0000000000600000
Part 2: DATA 0x0000000000600000 ---> 0x0000000000700000
Part 3: HOLE 0x0000000000700000 ---> 0x0000000001000000
SEEK(0x700000, SEEK_DATA) gets result (sr_eof:1, sr_offset:0x70000) from ganesha/gluster;
SEEK(0x700000, SEEK_HOLE) gets result (sr_eof:0, sr_offset:0x70000) from ganesha/gluster.
If an application depends the lseek result for data searching, it may enter infinite loop.
while (1) {
next_pos = lseek(fd, cur_pos, seek_type);
if (seek_type == SEEK_DATA) {
seek_type = SEEK_HOLE;
} else {
seek_type = SEEK_DATA;
}
if (next_pos == -1) {
return ;
cur_pos = next_pos;
}
The lseek syscall always gets 0x70000 from nfs client for those two cases,
but, if underlying filesystem is ext4/f2fs, or the nfs server is knfsd,
the lseek(0x700000, SEEK_DATA) gets ENXIO.
I wanna to know,
should I fix the ganesha/gluster as knfsd return ENXIO for the first case?
or should I fix the nfs client to return ENXIO for the first case?
thanks,
Kinglong Mee
4 years, 4 months
nfs-ganesha v2.8.5 ?
by Pasi Kärkkäinen
Hello all,
Is there a plan to release nfs-ganesha v2.8.5 ? It would be nice to have a new release in v2.8 branch with the latest fixes.
Thanks,
-- Pasi
4 years, 4 months
Announce Push of V4-dev.33
by Frank Filz
Branch next
Tag:V4-dev.33
Merge Highlights
* selinux and spec fixes
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
f55803d Frank S. Filz V4-dev.33
4c36324 Dimitri Savineau spec: remove %{_defaultdocdir}/ganesha directory
a7c76e6 Kaleb S. KEITHLEY selinux: non-fatal yum install error, conditional
on ceph-selinux
4 years, 4 months
Change in ...nfs-ganesha[next]: Specify & for inline asm output operands
by Matthew DeVore (GerritHub)
Matthew DeVore has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502162 )
Change subject: Specify & for inline asm output operands
......................................................................
Specify & for inline asm output operands
According to inline asm documentation for GCC:
Means (in a particular alternative) that this operand is an
earlyclobber operand, which is written before the instruction is
finished using the input operands. Therefore, this operand may not lie
in a register that is read by the instruction or as part of any memory
address.
Source: https://gcc.gnu.org/onlinedocs/gcc/Modifiers.html
This applies to many of the inline assembly snippets in atomic_x86_64.h.
The output operand at %1 is often used as the destination operand in the
first instruction. This could clobber the register which stores the
pointer to %0, which will result in an illegal operation in the lock...
instruction later on.
I discovered this while trying to build and run on macOS. While this may
not be affecting any supported platforms, it could cause problems (an
illegal memory access) if the compiler behavior ever changes, so it's
probably best to fix it.
Change-Id: I13762d2ec11488b2a54472f0f5afe12ce0a3a0c9
Signed-off-by: Matthew DeVore <matvore(a)google.com>
---
M src/include/atomic_x86_64.h
1 file changed, 15 insertions(+), 15 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/62/502162/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502162
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: I13762d2ec11488b2a54472f0f5afe12ce0a3a0c9
Gerrit-Change-Number: 502162
Gerrit-PatchSet: 1
Gerrit-Owner: Matthew DeVore <matvore(a)google.com>
Gerrit-MessageType: newchange
4 years, 4 months
Change in ...nfs-ganesha[next]: spec: remove %{_defaultdocdir}/ganesha directory
by Dimitri Savineau (GerritHub)
Dimitri Savineau has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502086 )
Change subject: spec: remove %{_defaultdocdir}/ganesha directory
......................................................................
spec: remove %{_defaultdocdir}/ganesha directory
We have:
%dir %{_defaultdocdir}/ganesha/
%{_defaultdocdir}/ganesha/*
But nothing is created in %{_defaultdocdir}/ganesha during the build so
the rpm build is failing.
Directory not found: BUILDROOT/nfs-ganesha-4-dev.31.el8.x86_64/usr/share/doc/ganesha
File not found: BUILDROOT/nfs-ganesha-4-dev.31.el8.x86_64/usr/share/doc/ganesha/*
Closes: #631
Signed-off-by: Dimitri Savineau <dsavinea(a)redhat.com>
Change-Id: I60b4b338519529821c1417ff61156d8c3ecd7eba
---
M src/nfs-ganesha.spec-in.cmake
1 file changed, 0 insertions(+), 2 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/86/502086/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/502086
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: I60b4b338519529821c1417ff61156d8c3ecd7eba
Gerrit-Change-Number: 502086
Gerrit-PatchSet: 1
Gerrit-Owner: Dimitri Savineau <savineau.dimitri(a)gmail.com>
Gerrit-MessageType: newchange
4 years, 4 months
