Re: [Nfs-ganesha-devel] How to disable MDCACHE completely in ganesha 2.5.1 from the configuration?

What code level? Your own FSAL? Unfortunately, mdcache can not be completely disabled because the handle cache is required. Are you also setting fileid in the fsal_obj_handle? The fileid, fsid, and type attributes are taken from the fsal_obj_handle rather than struct attrlist. This

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove non-support_ex setattrs FSAL method

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373993 Change subject: Remove non-support_ex setattrs FSAL method .. Remove non-support_ex setattrs

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove the non-support_ex read and write methods

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373992 Change subject: Remove the non-support_ex read and write methods .. Remove the non-support_ex

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove non-support_ex FSAL share_op method

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373996 Change subject: Remove non-support_ex FSAL share_op method .. Remove non-support_ex FSAL

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Replace calls to state_share_anonymous_io_start with state_d...

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373988 Change subject: Replace calls to state_share_anonymous_io_start with state_deleg_conflict ..

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Assume support_ex in NLM_SHARE/NLM_UNSHARE handling

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373987 Change subject: Assume support_ex in NLM_SHARE/NLM_UNSHARE handling .. Assume support_ex in

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove non-support_ex FSAL open, reopen, and status methods

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373998 Change subject: Remove non-support_ex FSAL open, reopen, and status methods .. Remove

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove support_ex FSAL method

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373991 Change subject: Remove support_ex FSAL method .. Remove support_ex FSAL method Change-Id:

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove non-support_ex FSAL commit method

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373997 Change subject: Remove non-support_ex FSAL commit method .. Remove non-support_ex FSAL commit

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove non-support_ex create FSAL method

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373994 Change subject: Remove non-support_ex create FSAL method .. Remove non-support_ex create FSAL

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: FSAL_RGW depends on FSAL status method that it doesn't imple...

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373979 Change subject: FSAL_RGW depends on FSAL status method that it doesn't implement .. FSAL_RGW

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Strip legacy state_share functions used by NFS4

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373986 Change subject: Strip legacy state_share functions used by NFS4 .. Strip legacy state_share

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Remove share counters from SAL - WARNING - delegations have ...

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373989 Change subject: Remove share counters from SAL - WARNING - delegations have been broken ..

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Disable do_lease_op - FSAL lock_op method is not implemented...

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373984 Change subject: Disable do_lease_op - FSAL lock_op method is not implemented by anyone ..

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Assume support_ex in SAL/nfs4_state.c

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373983 Change subject: Assume support_ex in SAL/nfs4_state.c .. Assume support_ex in SAL/nfs4_state.c

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Always assume support_ex in NFS3 protocol functions

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373981 Change subject: Always assume support_ex in NFS3 protocol functions .. Always assume support_ex

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Assume support_ex in SAL/state_lock.c

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373985 Change subject: Assume support_ex in SAL/state_lock.c .. Assume support_ex in SAL/state_lock.c

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Always assume support_ex in 9p

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373980 Change subject: Always assume support_ex in 9p .. Always assume support_ex in 9p Change-Id:

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Assume support_ex in NFS4 protocol functions

>From Frank Filz : Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/373982 Change subject: Assume support_ex in NFS4 protocol functions .. Assume support_ex in NFS4

Re: [Nfs-ganesha-devel] How to disable MDCACHE completely in ganesha 2.5.1 from the configuration?

The observation that I am trying to troubleshoot is this: I am setting fsalattr->valid_mask |= ATTRS_POSIX; and fsalattr->fileid to a valid non-zero value. I print those in FSAL log and it comes as expected before going on wire. But in pcap trace I see that the value sent is zero. On the client

[Nfs-ganesha-devel] How to disable MDCACHE completely in ganesha 2.5.1 from the configuration?

Hi, Is there an option to disable caching from the configuration files? I am debugging an issue and want to rule out that caching is causing trouble. Thanks. -- Check out the vibrant tech community on one of the world's

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

On 08/11/2017 12:10 PM, Frank Filz wrote: Right, this is reaping. I was thinking it was the lane thread. Reaping only looks at the single LRU of each queue. We should probably look at some small number of each lane, like 2 or 3. Frank, this, in combination with the PIN lane, it probably the

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Manpage - Fix installing manpages in RPM

>From Daniel Gryniewicz : Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/373956 Change subject: Manpage - Fix installing manpages in RPM .. Manpage - Fix installing

Re: [Nfs-ganesha-devel] Weekly conference call timing

It seems like we have converged on the hour earlier time slot on Tuesdays, so let's start next week. Thanks Frank > -Original Message- > From: Frank Filz [mailto:ffilz...@mindspring.com] > Sent: Wednesday, August 9, 2017 12:48 PM > To: nfs-ganesha-devel@lists.sourceforge.net > Subject:

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

> Right, this is reaping. I was thinking it was the lane thread. Reaping only > looks at the single LRU of each queue. We should probably look at some > small number of each lane, like 2 or 3. > > Frank, this, in combination with the PIN lane, it probably the issue. Yea, that would be a

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

Right, this is reaping. I was thinking it was the lane thread. Reaping only looks at the single LRU of each queue. We should probably look at some small number of each lane, like 2 or 3. Frank, this, in combination with the PIN lane, it probably the issue. Daniel On 08/11/2017 11:21 AM,

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

It's not supposed to, as presently defined, right (scan resistence)? Matt On Fri, Aug 11, 2017 at 11:48 AM, Daniel Gryniewicz wrote: > On 08/11/2017 09:21 AM, Frank Filz wrote: >>> >>> That seems overkill to me. How many strategies would we support (and >>> test)? >>> >>> Part

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

On 08/11/2017 09:21 AM, Frank Filz wrote: That seems overkill to me. How many strategies would we support (and test)? Part of the problem is that we've drastically changed how FDs are handled. We need to rethink how LRU should work in that context, I think. I wonder also if taking pinning

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

Hi Daniel, I'm testing with 2.5.1. I haven't changed those parameters. Those parameters only affect once you are in lru_run_lane(), right? Since the FDs are lower than low-watermark, it never calls lru_run_lane(). Thanks, Pradeep On Fri, Aug 11, 2017 at 5:43 AM, Daniel Gryniewicz

Re: [Nfs-ganesha-devel] crash in makefd_xprt()

On 8/11/17 8:35 AM, Matt Benjamin wrote: On Fri, Aug 11, 2017 at 8:26 AM, William Allen Simpson wrote: On 8/11/17 2:29 AM, Malahal Naineni wrote: Following confirms that Thread1 (TCP) is trying to use the same "rec" as Thread42 (UDP), it is easy to reproduce

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

initially, just a couple--but the strategizing step forces an internal api to develop. Matt On Fri, Aug 11, 2017 at 8:49 AM, Daniel Gryniewicz wrote: > That seems overkill to me. How many strategies would we support (and test)? > > Part of the problem is that we've drastically

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

Have you set Reaper_Work? Have you changed LRU_N_Q_LANES? (and which version of Ganesha?) Daniel On 08/10/2017 07:12 PM, Pradeep wrote: Debugged this a little more. It appears that the entries that can be reaped are not at the LRU position (head) of the L1 queue. So those can be free'd

Re: [Nfs-ganesha-devel] crash in makefd_xprt()

I didn't recall this reached 2.5, independent of the current rework. (offhand, what branch shows the tree consolidation in 2015?) In any case though, perhaps we should start from pulling up the ntirpc experimentally. Matt On Fri, Aug 11, 2017 at 8:26 AM, William Allen Simpson

Re: [Nfs-ganesha-devel] crash in makefd_xprt()

On 8/11/17 2:29 AM, Malahal Naineni wrote: Following confirms that Thread1 (TCP) is trying to use the same "rec" as Thread42 (UDP), it is easy to reproduce on the customer system! There are 2 duplicated fd indexed trees, not well coordinated. My 2015 code to fix this went in Feb/Mar