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
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
Kerberos Progress
by Frank Filz
I made some progress on the Kerberos stuff.
For Integrity, Daniel's fix didn't quite work because it didn't account for
the length of the mic token length field.
Instead of doing a SETPOS, I fixed up the xdrs directly with the tail of the
last buffer.
I also re-organized the xdr_iov for XDR_ALLOCHDR to explicitly have a buffer
for the length field (which is not part of the gss_iov). This makes the
debug code work better.
Now krb5 and krb5i work, but krb5p doesn't work, so a bit more debug to
figure out what's wrong there. I suspect a similar problem with the length
of the output, but it needs to be fixed up a little differently.
Frank
5 years, 1 month
Change in ...nfs-ganesha[next]: krb5 pullup
by Frank Filz (GerritHub)
Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/472817 )
Change subject: krb5 pullup
......................................................................
krb5 pullup
Change-Id: Ie3aa6a2b6c7d299a617bf6d97300af71468be3df
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
---
M src/libntirpc
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/17/472817/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/472817
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: Ie3aa6a2b6c7d299a617bf6d97300af71468be3df
Gerrit-Change-Number: 472817
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>
Gerrit-MessageType: newchange
5 years, 1 month
Change in ...nfs-ganesha[next]: Update ganesha_mgr options consistency.
by xijinyu (GerritHub)
xijinyu has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/472666 )
Change subject: Update ganesha_mgr options consistency.
......................................................................
Update ganesha_mgr options consistency.
The options modified according to USAGE.
For examples:
Use "ganesha_mgr show exports", rather than "ganesha show_exports";
Use "ganesha_mgr show version", rather than "ganesha show_version".
Signed-off-by: Xi Jinyu <xijinyu(a)cmss.chinamobile.com>
Change-Id: Iec6ef39ab8cf0c1cb5d936c59c0dc977b589ad48
---
M src/scripts/ganeshactl/ganesha_mgr.py
1 file changed, 141 insertions(+), 86 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/66/472666/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/472666
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: Iec6ef39ab8cf0c1cb5d936c59c0dc977b589ad48
Gerrit-Change-Number: 472666
Gerrit-PatchSet: 1
Gerrit-Owner: xijinyu <xijinyu(a)cmss.chinamobile.com>
Gerrit-MessageType: newchange
5 years, 2 months
Nfsv4 name to uid lookup while doing chown
by Jerrad Bieno
We have ganesha configured to not do any userid lookups for v4, by doing
the following:
1. Using "-USE_NFSIDMAP=OFF" compile argument.
2. UseGetpwnam set to false and allow_numeric_owners to true in the nfsv4
configuration
This eliminated the user lookups for the most part, but we occasionally
noticed that when doing a chown to a uid that the client didn't know, that
was getting passed to ganesha as a uid and ganesha was then
interpreting this as a user name and trying to do a name to id lookup
via name2id method in /idmapper/idmapper.c which does a getpwam call that
is not checked for the configuration options like other similar calls. Is
this a bug that it is doing a getpwnam_r even though UseGetpwnam is set to
false? Additionally, why does ganesha ever need to lookup users by name?
I'm surprised that it would ever get user names from a client and wouldn't
need to do a name to id lookup. The chown is passing an id in this case. We
are using ganesha 2.5.5.
5 years, 2 months
Change in ...nfs-ganesha[next]: [GPFS] workaround for lookup of parent entry (DOTDOT)
by Malahal (GerritHub)
Malahal has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/472446 )
Change subject: [GPFS] workaround for lookup of parent entry (DOTDOT)
......................................................................
[GPFS] workaround for lookup of parent entry (DOTDOT)
Sometimes we receive invalid handle from lookup of "..", handle
it by sending DELAY error and hope it goes away in a retry!
Also, We shouldn't be sending a lookup of ".." in an export root or root
of the GPFS file system. If we do ever send, we get an ENOENT from GPFS,
so handle it gracefully.
Change-Id: I021b4a88542395a746b05242dbbbc92fbedd32b0
Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com>
---
M src/FSAL/FSAL_GPFS/fsal_lookup.c
M src/FSAL/FSAL_GPFS/handle.c
2 files changed, 56 insertions(+), 12 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/46/472446/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/472446
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: I021b4a88542395a746b05242dbbbc92fbedd32b0
Gerrit-Change-Number: 472446
Gerrit-PatchSet: 1
Gerrit-Owner: Malahal <malahal(a)gmail.com>
Gerrit-MessageType: newchange
5 years, 2 months
Announce Push of V3.0-rc4
by Frank Filz
Branch next
Tag:V3.0-rc4
Release Highlights
* Make nfsv3 and nfsv4 use container_of(req, nfs_request_t, svc) to get
reqdata
* RADOS KV - Don't deref size, it may be NULL
* build: remove librados dependency on ganesha.nfsd
* Fix variable name.
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
de545e7 Frank S. Filz V3.0-rc4
c85a601 Xi Jinyu Fix variable name.
f898487 TweakySolution NFS v4 read/write request callback reqdata.
1a61dd7 TweakySolution NFS v3 read/write request callback reqdata.
0fea990 Kaleb S. KEITHLEY build: remove librados dependency on ganesha.nfsd
4f0329c Daniel Gryniewicz RADOS KV - Don't deref size, it may be NULL
5 years, 2 months
Nfs-Ganesha 2.6.3 - NFSv3 - Share hangs after couple of days
by Satish Chandra Kilaru
I have been dumping several TBs of data over the last few days. I noticed that my copy operations have been hanging for several hours. My ganesha.log is flooded with the below log.
[cache_lru] lru_run :INODE LRU :CRIT :Futility count exceeded. The LRU thread is unable to make progress in reclaiming FDs, will try harder.
I turned on full debug logs and I see the following logs. Looks like it is not closing any FDs.
24/10/2019 13:20:50 : epoch 5da91d15 : paplbur04.telecom.tcnz.net : ganesha.nfsd-101379[cache_lru] lru_run :INODE LRU :F_DBG :LRU awakes.
24/10/2019 13:20:50 : epoch 5da91d15 : paplbur04.telecom.tcnz.net : ganesha.nfsd-101379[cache_lru] lru_run :INODE LRU :F_DBG :lru entries: 51444
24/10/2019 13:20:50 : epoch 5da91d15 : paplbur04.telecom.tcnz.net : ganesha.nfsd-101379[cache_lru] lru_run :INODE LRU :DEBUG :Open FDs over high water mark, reapring aggressively.
24/10/2019 13:20:50 : epoch 5da91d15 : paplbur04.telecom.tcnz.net : ganesha.nfsd-101379[chunk_lru] chunk_lru_run :INODE LRU :F_DBG :LRU awakes, lru chunks used: 337
24/10/2019 13:20:50 : epoch 5da91d15 : paplbur04.telecom.tcnz.net : ganesha.nfsd-101379[cache_lru] lru_run :INODE LRU :DEBUG :Reaping up to 50 entries from lane 0
.
.
.
.
24/10/2019 13:20:50 : epoch 5da91d15 : paplbur04.telecom.tcnz.net : ganesha.nfsd-101379[cache_lru] lru_run_lane :INODE LRU :DEBUG :Actually processed 50 entries on lane 0 closing 0 descriptors
I checked the source code and looks like FD is not closed because of this block. What could cause this ref-count to go above 2? This is my own FSAL. Could the FSAL be not decreasing the ref-count? I dont seem to have this problem with NFSv4.
FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c
/* check refcnt in range */
if (unlikely(refcnt > 2)) {
/* This unref is ok to be done without a valid op_ctx
* because we always map a new entry to an export before
* we could possibly release references in
* mdcache_new_entry.
*/
QUNLOCK(qlane);
mdcache_lru_unref(entry);
goto next_lru;
}
I can attach the full log file in the next email if required. I don't have logs at the full-debug level when it was working fine.
5 years, 2 months
Change in ...nfs-ganesha[next]: Fix variable name.
by xijinyu (GerritHub)
xijinyu has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/472235 )
Change subject: Fix variable name.
......................................................................
Fix variable name.
Signed-off-by: Xi Jinyu <xijinyu(a)cmss.chinamobile.com>
Change-Id: Ia522be278666d20029334d36b0c11418c38a2243
---
M src/scripts/ganeshactl/Ganesha/ganesha_mgr_utils.py
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/35/472235/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/472235
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: Ia522be278666d20029334d36b0c11418c38a2243
Gerrit-Change-Number: 472235
Gerrit-PatchSet: 1
Gerrit-Owner: xijinyu <xijinyu(a)cmss.chinamobile.com>
Gerrit-MessageType: newchange
5 years, 2 months
