Change in ...nfs-ganesha[next]: Allow EXPORT pseudo path to be changed during export update
by Frank Filz (GerritHub)
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
10 months, 1 week
Change in ...nfs-ganesha[next]: MDCACHE - Add MDCACHE {} config block
by Daniel Gryniewicz (GerritHub)
Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/454929
Change subject: MDCACHE - Add MDCACHE {} config block
......................................................................
MDCACHE - Add MDCACHE {} config block
Add a config block name MDCACHE that is a copy of CACHEINODE. Both can
be configured, but MDCACHE will override CACHEINODE. This allows us to
deprecate CACHEINODE.
Change-Id: I49012723132ae6105b904a60d1a96bb2bf78d51b
Signed-off-by: Daniel Gryniewicz <dang(a)fprintf.net>
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_read_conf.c
M src/config_samples/ceph.conf
M src/config_samples/config.txt
M src/config_samples/ganesha.conf.example
M src/doc/man/ganesha-cache-config.rst
M src/doc/man/ganesha-config.rst
6 files changed, 31 insertions(+), 7 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/29/454929/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/454929
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: I49012723132ae6105b904a60d1a96bb2bf78d51b
Gerrit-Change-Number: 454929
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com>
Gerrit-MessageType: newchange
4 years, 1 month
Issues seen with krb5i and krb5p mounts
by Trishali Nayar
Hi all,
There are a few clients eg- Ubuntu 18.04.3 (4.15.0-55-generic) and RH7.8
(3.10.0-1127.el7.x86_64) for which we have observed... simple command like
'dd' either hangs or returns EIO. This is happening only on krb5i and krb5p
mounts. It seems to happen for file sizes eg- 100MB and larger mostly. But
sometimes even a 30 MB file sees failures.
A client eg- RH7.6 (3.10.0-957.el7.x86_64) does not seem to hit this
issue...so might be with more recent kernels?
We fixed the issue with check-in
https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/490802 The idea was to
let clients know that Ganesha denied the request VS just dropping the
request.
This fix did seem to help and hangs/errors stopped completely... but for
larger file sizes eg- 1000MB we started seeing "Permission Denied" errors.
This was different than the EIO errors seen earlier. Reason could be we are
now sending an "AUTH DENIED" error so clients translate it to this new
error.
We tried to add more logging into Ganesha and observe that these particular
clients seem to send a lot of requests together. When we process same, the
sequence no. is pretty much out or order and we drop the requests outside
the sequence window, as per the RFC 2203 Section 7.2.1. The sequence window
that we have is 32.
Testing these clients with kNFS does not hit the issue...The kNFS sequence
window seems to be larger and is 128.
So, tried to increase the sequence window as well to 128 for ganesha. That
does not seem to help fix the issue.
We also have below additional 'seqmask' check and many of the requests went
into that category as well and were dropped.
"libntirpc/src/svc_auth_gss.c":
} else if (offset >= gd->win || (gd->seqmask & (1 << offset))) {
*no_dispatch = true;
goto gd_free;
}
Also observed that now these clients sent many requests above the 128
window...which we would again drop.
Wondering what is the proper way to fix this and any idea on what these
clients are doing different.
Thanks and regards,
Trishali.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trishali Nayar
IBM Systems
ETZ, Pune.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4 years, 2 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, 3 months
Re: segfault in nfs_rpc_destroy_chan while releasing xprt
by Deepthi Shivaramu
Soumya,
I see there was discussion in github about the exact same segfault and you were debugging this issue :
https://github.com/nfs-ganesha/ntirpc/issues/153
There were multiple fixes discussed in there but ultimately I see this fix was checked in :
https://github.com/nfs-ganesha/ntirpc/pull/155/commits/ca74cde10ef02a322b...
But the strange part is I have that fix already in my source and still hitting this same segfault.
Also one correction from my previous mail, actually we are using libntirpc1.7.0 with ganesha2.7.2.
@Soumya, do you know any other fix which was related to this problem?
Regards,
Deepthi
On 14/05/20, 5:09 PM, "Deepthi Shivaramu" <des(a)vmware.com> wrote:
I see this segfault is in nfs_rpc_destroy_chan() and not specific to setclientid_confirm.
We are not seeing it with NFSv4.1 but seeing it frequently with NFSv4.0 tests.
I saw one more core today with bt:
(gdb) bt
#0 0x00007ff7b1dde71a in svc_release_it (xprt=0x7ff780001740, flags=0, tag=0x7ff7b1e05fd0 "clnt_vc_destroy", line=462)
at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/svc.h:433
#1 0x00007ff7b1ddf4fb in clnt_vc_destroy (clnt=0x7ff780001620) at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/src/clnt_vc.c:462
#2 0x000000000043b4e1 in clnt_release_it (clnt=0x7ff780001620, flags=0, tag=0x55e550 <__func__.21824> "_nfs_rpc_destroy_chan", line=628)
at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/clnt.h:319
#3 0x000000000043b577 in clnt_destroy_it (clnt=0x7ff780001620, tag=0x55e550 <__func__.21824> "_nfs_rpc_destroy_chan", line=628)
at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/clnt.h:341
#4 0x000000000043eb97 in _nfs_rpc_destroy_chan (chan=0x7ff7940023a8) at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/MainNFSD/nfs_rpc_callback.c:628
#5 0x000000000043f800 in nfs_rpc_destroy_chan (chan=0x7ff7940023a8) at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/MainNFSD/nfs_rpc_callback.c:864
#6 0x00000000004bde35 in nfs_client_id_expire (clientid=0x7ff794002300, make_stale=false)
at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/SAL/nfs4_clientid.c:1099
#7 0x00000000004442bf in reap_hash_table (ht_reap=0xf35f40) at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/MainNFSD/nfs_reaper_thread.c:109
#8 0x0000000000444a62 in reaper_run (ctx=0xf66ca0) at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/MainNFSD/nfs_reaper_thread.c:232
#9 0x00000000004fdc38 in fridgethr_start_routine (arg=0xf66ca0) at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/support/fridgethr.c:550
#10 0x00007ff7b09aa3d4 in start_thread (arg=0x7ff791ffb700) at pthread_create.c:334
#11 0x00007ff7b02c9ebd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) f 0
#0 0x00007ff7b1dde71a in svc_release_it (xprt=0x7ff780001740, flags=0, tag=0x7ff7b1e05fd0 "clnt_vc_destroy", line=462)
at /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/svc.h:433
433 in /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/svc.h
(gdb) p xprt
$1 = (SVCXPRT *) 0x7ff780001740
(gdb) p *$
$2 = {xp_ops = 0x0, xp_dispatch = {process_cb = 0x0, rendezvous_cb = 0x0}, xp_parent = 0x7ff770004730, xp_tp = 0x6d00000001 <error: Cannot access memory at address 0x6d00000001>,
xp_netid = 0x7ff79c00a160 "", xp_p1 = 0x7ff770004750, xp_p2 = 0x0, xp_p3 = 0x0, xp_u1 = 0x3, xp_u2 = 0x0, xp_local = {nb = {maxlen = 0, len = 0, buf = 0x7ff7940018a0}, ss = {
ss_family = 0, __ss_align = 0, __ss_padding = '\000' <repeats 111 times>}}, xp_remote = {nb = {maxlen = 4280583506, len = 0, buf = 0x0}, ss = {ss_family = 34467,
__ss_align = 1,
__ss_padding = "_:P\346ju\200\223\001\000\000\000\001\000\000\000`,\000\200\367\177\000\000\341\376\266^", '\000' <repeats 12 times>, "\061\000\000\000\000\000\000\000\000\061\000\200\367\177\000\000\220]\000\200\367\177\000\000c3-edbe-2fea12000\000\000\000\000\000\000\000\064\001", '\000' <repeats 21 times>}}, xp_lock = {__data = {__lock = -1946148624,
__count = 32759, __owner = 0, __nusers = 37, __kind = -1946148624, __spins = 32759, __list = {__prev = 0x7ff77c001530, __next = 0x0}},
__size = "\360 \000\214\367\177\000\000\000\000\000\000%\000\000\000\360 \000\214\367\177\000\000\060\025\000|\367\177\000\000\000\000\000\000\000\000\000",
__align = 140701182468336}, xp_fd = 0, xp_ifindex = 0, xp_si_type = 3, xp_type = 0, xp_refcnt = -1, xp_flags = 64}
(gdb) p xprt->xp_ops
$3 = (struct xp_ops *) 0x0
(gdb)
Regards,
Deepthi
On 14/05/20, 12:17 PM, "Deepthi Shivaramu" <des(a)vmware.com> wrote:
Daniel,
I am seeing this segfault in the libntirpc1.8.0 with ganesha2.8.2 in setclientid_confirm code path.
Can you please check and let me know if you have seen this issue before and if the fix is already available in latest versions?
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007fd66badf72e in svc_release_it (xprt=0x7fd658002e90, flags=0,
tag=0x7fd66bb06fd0 "clnt_vc_destroy", line=462)
at
/build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/svc.h:433
#2 0x00007fd66bae04fb in clnt_vc_destroy (clnt=0x7fd658002ba0)
at
/build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/src/clnt_vc.c:462
#3 0x000000000043b4e1 in clnt_release_it (clnt=0x7fd658002ba0, flags=0,
tag=0x55e550 <__func__.21824> "_nfs_rpc_destroy_chan", line=628)
at
/build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/clnt.h:319
#4 0x000000000043b577 in clnt_destroy_it (clnt=0x7fd658002ba0,
tag=0x55e550 <__func__.21824> "_nfs_rpc_destroy_chan", line=628)
at
/build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/clnt.h:341
#5 0x000000000043eb97 in _nfs_rpc_destroy_chan (chan=0x7fd64c002648)
at
/build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/MainNFSD/nfs_rpc_callback.c:628
#6 0x000000000043f800 in nfs_rpc_destroy_chan (chan=0x7fd64c002648)
at
/build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/MainNFSD/nfs_rpc_callback.c:864
#7 0x000000000048011c in nfs4_op_setclientid_confirm (op=0x7fd62c001d90,
---Type <return> to continue, or q <return> to quit---
data=0x7fd6607dff70, resp=0x7fd62c002070)
at
/build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/Protocols/NFS/nfs4_op_setclientid_confirm.c:382
#8 0x000000000045b4b1 in nfs4_Compound (arg=0x7fd62c0011a8,
req=0x7fd62c000aa0, res=0x7fd62c001f60)
at
....
.......
#20 0x00007fd669fcaebd in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) f 1
#1 0x00007fd66badf72e in svc_release_it (xprt=0x7fd658002e90, flags=0,
tag=0x7fd66bb06fd0 "clnt_vc_destroy", line=462)
at
/build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/svc.h:433
433 /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/libntirpc/ntirpc/rpc/svc.h:
No such file or directory.
(gdb) p clnt
No symbol "clnt" in current context.
(gdb) p xprt
$10 = (SVCXPRT *) 0x7fd658002e90
(gdb) p *$
$11 = {xp_ops = 0x7fd658000e20, xp_dispatch = {process_cb = 0x7fd658000078,
rendezvous_cb = 0x7fd658000078}, xp_parent = 0x0, xp_tp = 0x0,
xp_netid = 0x0, xp_p1 = 0x0, xp_p2 = 0x0, xp_p3 = 0x0, xp_u1 = 0x0,
xp_u2 = 0x0, xp_local = {nb = {maxlen = 483619223, len = 1, buf = 0x2},
ss = {ss_family = 0, __ss_align = 0,
__ss_padding =
"\313)\260k\326\177\000\000\020\320\236b\326\177\000\000\006\000\000\000\034\000\000\000\004\004\005\377\377\377\377\377\000\000\000\000\020\373\364\310\333c\335\363\245\332\362b\324.M\332",
'\000' <repeats 59 times>}}, xp_remote = {nb = {maxlen = 0, len = 0, buf =
0x0}, ss = {ss_family = 0,
__ss_align = 0, __ss_padding = '\000' <repeats 111 times>}}, xp_lock =
{
__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0,
__spins = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = '\000' <repeats 39 times>, __align = 0}, xp_fd = 0,
xp_ifindex = 0, xp_si_type = 0, xp_type = 0, xp_refcnt = -1, xp_flags = 64}
(gdb) f 6
#6 0x000000000043f800 in nfs_rpc_destroy_chan (chan=0x7fd64c002648)
at
/build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/MainNFSD/nfs_rpc_callback.c:864
864 /build/mts/release/bora-16138726/cayman_nfs-ganesha/nfs-ganesha/src/src/MainNFSD/nfs_rpc_callback.c:
No such file or directory.
(gdb) p chan
$12 = (rpc_call_channel_t *) 0x7fd64c002648
(gdb) p *$
$13 = {type = RPC_CHAN_V40, mtx = {__data = {__lock = 1, __count = 0,
__owner = 163, __nusers = 1, __kind = 0, __spins = 0, __list = {
__prev = 0x0, __next = 0x0}},
__size = "\001\000\000\000\000\000\000\000\243\000\000\000\001",
'\000' <repeats 26 times>, __align = 1}, states = 0, source = {clientid =
0x7fd64c0025a0,
session = 0x7fd64c0025a0}, last_called = 0, clnt = 0x7fd658002ba0,
auth = 0x0, gss_sec = {mech = 0x0, qop = 0, svc = RPCSEC_GSS_SVC_INTEGRITY,
cred = 0x0, req_flags = 0}}
(gdb) p chan->client
There is no member named client.
(gdb) p chan->clnt
$14 = (CLIENT *) 0x7fd658002ba0
(gdb) p *$
$15 = {cl_ops = 0x7fd66bd192e0, cl_netid = 0x0, cl_tp = 0x0, cl_u1 = 0x0,
cl_u2 = 0x0, cl_lock = {__data = {__lock = 0, __count = 0, __owner = 0,
__nusers = 0, __kind = 3, __spins = 0, __list = {__prev = 0x0,
__next = 0x0}},
__size = '\000' <repeats 16 times>, "\003", '\000'
<repeats 22 times>,
__align = 0}, cl_error = {ru = {RE_errno = 0, RE_why = AUTH_OK, RE_vers = {
low = 0, high = 0}, RE_lb = {s1 = 0, s2 = 0}},
re_status = RPC_SUCCESS}, cl_refcnt = 0, cl_flags = 96}
(gdb)
On 06/05/20, 10:00 PM, "Daniel Gryniewicz" <dang(a)redhat.com> wrote:
I'm happy to announce the latest stable versions of NTIRPC and Ganesha
in the 2.8 series. These are NTIRPC 1.8.1 and Ganesha 2.8.4. There are
>40 bug fixes in these releases.
Daniel
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
4 years, 6 months
Change in ...nfs-ganesha[next]: For Discussion - revert 61c83b - Do not downgrade on reopen.
by Frank Filz (GerritHub)
Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494573 )
Change subject: For Discussion - revert 61c83b - Do not downgrade on reopen.
......................................................................
For Discussion - revert 61c83b - Do not downgrade on reopen.
I didn't check before merging, the patch causes 3 pynfs tests to
fail, which is a regression. I'm not sure how to address, but we
need something open for discussion.
Change-Id: Ia78125d6acc97529349f01c72afb045c67ab342c
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
---
M src/Protocols/NFS/nfs4_op_open.c
1 file changed, 11 insertions(+), 14 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/73/494573/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494573
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: Ia78125d6acc97529349f01c72afb045c67ab342c
Gerrit-Change-Number: 494573
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>
Gerrit-MessageType: newchange
4 years, 7 months
Announce Push of V4-dev.19
by Frank Filz
Branch next
Tag:V4-dev.19
Merge Highlights
* bugfix: initialization ea_entry->e_perm before get permission value
* Stop reaper threads before worker threads when shutting down
* EXPORT: Set expire_time_attr for export root.
* build: fix doc build for the NFS v3 Proxy
* Add NFSv4.1 and NFSv4.2 io stats.
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
3f6d35f Frank S. Filz V4-dev.19
b15d5cb Xi Jinyu Add NFSv4.1 and NFSv4.2 io stats.
9da41b9 Denis Kondratenko build: fix doc build for the NFS v3 Proxy
d027e49 Pradeep EXPORT: Set expire_time_attr for export root.
fa8c43e Sriram Patil Stop reaper threads before worker threads when shutting
down
3136c9e Luo Muyao bugfix: initialization ea_entry->e_perm before get
permission value
4 years, 7 months
Change in ...nfs-ganesha[next]: MDCACHE: add lru release entries process
by sepia-liu (GerritHub)
sepia-liu has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494502 )
Change subject: MDCACHE: add lru release entries process
......................................................................
MDCACHE: add lru release entries process
If something refs a lot of entries at the same time and above the
high water mark, we have no way to release cache entries below water
level,though it can be released.
By adding this process, every time we can try best to release the number
of entries until entries used below the water level, the max number of
release per time is Entries_Release_Size.
Change-Id: Ibe363d2649936086ccd5a0485709b20622c39efc
Signed-off-by: sepia-liu <liuwei_coder(a)163.com>
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_debug.h
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_ext.h
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.h
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_read_conf.c
M src/config_samples/config.txt
M src/doc/man/ganesha-cache-config.rst
7 files changed, 70 insertions(+), 14 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/02/494502/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494502
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: Ibe363d2649936086ccd5a0485709b20622c39efc
Gerrit-Change-Number: 494502
Gerrit-PatchSet: 1
Gerrit-Owner: sepia-liu <liuwei_coder(a)163.com>
Gerrit-MessageType: newchange
4 years, 7 months
Change in ...nfs-ganesha[next]: fix nfs client IO hang during heavy workload
by Peng Xie (GerritHub)
Peng Xie has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494411 )
Change subject: fix nfs client IO hang during heavy workload
......................................................................
fix nfs client IO hang during heavy workload
the hang was introduced in the following case:
1. nfs client send IO-1 to the nfs ganesha, where it first goes
into the drc and makerd DUPREQ_START.
2. the IO-1 stucked and being processed very slow in the ganesha
server due to heavy io workload and unfortunately, the nfs client
and ganesha server experienced network timedout and nfs client
issued reconnect then retry IO-1
3. the step-2's retry IO-1 enters into the ganesha drc and found
the same xid request is BEING_PROCESSED, so it will do nothing
and directly returned under the assumption that after step-1 's
IO-1 completed, it will reply to the nfs client.
4. after step-1 's IO-1 completion, when trying to reply the client,
it found the XPRT_DESTROYED due to the previous nfs client reconnect,
and the reply will be dropped.
Finally, the nfs client will forever hang and ganesha server will never
reply the IO.
Change-Id: Ic917450afc09a0090ce3de42ed464f168d1623a8
Signed-off-by: Peng Xie <peng.hse(a)xtaotech.com>
---
M src/MainNFSD/nfs_worker_thread.c
M src/RPCAL/nfs_dupreq.c
M src/include/nfs_dupreq.h
3 files changed, 29 insertions(+), 27 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/11/494411/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494411
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: Ic917450afc09a0090ce3de42ed464f168d1623a8
Gerrit-Change-Number: 494411
Gerrit-PatchSet: 1
Gerrit-Owner: Peng Xie <hsepeng(a)qq.com>
Gerrit-MessageType: newchange
4 years, 7 months
Change in ...nfs-ganesha[next]: MDCACHE: add process of adjusting lru entries order
by sepia-liu (GerritHub)
sepia-liu has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494408 )
Change subject: MDCACHE: add process of adjusting lru entries order
......................................................................
MDCACHE: add process of adjusting lru entries order
If the root object appears in the head of LRU, it will block
the lru object reaping and entries releasing. By adjusting
the root entry to the tail of LRU, let next entry be released.
Change-Id: Id1a17b26cc51d629642097852f20c4a2c2e5cf41
Signed-off-by: sepia-liu <liuwei_coder(a)163.com>
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.h
2 files changed, 73 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/08/494408/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/494408
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: Id1a17b26cc51d629642097852f20c4a2c2e5cf41
Gerrit-Change-Number: 494408
Gerrit-PatchSet: 1
Gerrit-Owner: sepia-liu <liuwei_coder(a)163.com>
Gerrit-MessageType: newchange
4 years, 7 months
