October 2019 - Devel - NFS Ganesha List Archives

Change in ...nfs-ganesha[next]: MDCACHE - Add MDCACHE {} config block
by Daniel Gryniewicz (GerritHub) 05 Nov '20

05 Nov '20

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

3 2

lseek gets bad offset from nfs client with ganesha/gluster which supports SEEK
by Kinglong Mee 14 Sep '20

14 Sep '20

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 8

Kerberos Progress
by Frank Filz 30 Oct '19

30 Oct '19

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

2 2

Change in ...nfs-ganesha[next]: krb5 pullup
by Frank Filz (GerritHub) 30 Oct '19

30 Oct '19

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

1 0

Change in ...nfs-ganesha[next]: Update ganesha_mgr options consistency.
by xijinyu (GerritHub) 28 Oct '19

28 Oct '19

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

1 0

Nfsv4 name to uid lookup while doing chown
by Jerrad Bieno 28 Oct '19

28 Oct '19

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.

2 1

Change in ...nfs-ganesha[next]: [GPFS] workaround for lookup of parent entry (DOTDOT)
by Malahal (GerritHub) 26 Oct '19

26 Oct '19

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

1 0

Announce Push of V3.0-rc4
by Frank Filz 25 Oct '19

25 Oct '19

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

1 0

Nfs-Ganesha 2.6.3 - NFSv3 - Share hangs after couple of days
by Satish Chandra Kilaru 24 Oct '19

24 Oct '19

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.

2 2

Change in ...nfs-ganesha[next]: Fix variable name.
by xijinyu (GerritHub) 23 Oct '19

23 Oct '19

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

1 0