Branch next
Tag:V2.6-dev-4
Release Highlights
* Ensure partition lock and qlane lock ordering
* Set op_ctx when calling mdcache_lru_clean() in the context of background
thread.
* Fixed mappings of Detached_Mult and Dir_Chunk to the right
mdcache_parameter.
* Various build and packaging fixes
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 al
>From Frank Filz :
Frank Filz has uploaded this change for review. (
https://review.gerrithub.io/373995
Change subject: Remove non-support_ex lock_op and fso_lock_support_owner
..
Remove non-support_ex lock_op and fso_lock_sup
>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 share_op method
Change-Id: I042a
>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 FSAL method
Change-Id: I7c98
>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 read and write methods
Chan
>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
..
Replace calls to state_share
>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 NLM_SHARE/NLM_UNSHARE handling
>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 non-support_ex FSAL open, reopen, an
>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: I09e17c305ba4c90e2699251940649a
>From Frank Filz :
Frank Filz has uploaded this change for review. (
https://review.gerrithub.io/373990
Change subject: Assume support_ex in FSAL/fsal_helper.c and include/fsal.h
..
Assume support_ex in FSAL/fsal_helper.c and
>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 method
Change-Id: If40959b0
>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 method
Change-Id: I01405fe6
>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 depends on FSAL status method
>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 functions used by NFS4
state_
>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
..
Remove share counters from SAL
>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
..
Disable do_lease_op - FSAL lock
>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
Change-Id: Ic3cf431ccb02f3
>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 in NFS3 protocol functions
>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
Since support_ex is assume
>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: I1505e5e606d2a360e3c58833d692
>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 protocol functions
Change-Id: I
>From Frank Filz :
Frank Filz has uploaded this change for review. (
https://review.gerrithub.io/373978
Change subject: Strip FSAL_ZFS out
..
Strip FSAL_ZFS out
The legacy (non-support_ex) FSAL API is on its way out. FSAL_ZFS
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 tr
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
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 i
>From Daniel Gryniewicz :
Daniel Gryniewicz has uploaded this change for review. (
https://review.gerrithub.io/373957
Change subject: New (empty) sample config
..
New (empty) sample config
Other projects that want to interact
>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 manpages in RPM
Move t
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: [
> 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 proble
yes, this is one of the things I thought we might parameterise
On Fri, Aug 11, 2017 at 11:52 AM, Daniel Gryniewicz 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 eac
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, Pr
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 of the problem is
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 out
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 wrote:
> Have
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 on the customer system!
There ar
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 changed how FDs a
> 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 out of the equation (which moved cache
On 8/9/17 3:48 PM, Frank Filz wrote:
My daughter will be starting a new preschool, possibly as early as August
22nd. Unfortunately since it's Monday, Tuesday, Wednesday and I will need to
drop her off at 9:00 AM Pacific Time, which is right in the middle of our
current time slot...
We could keep
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.
Daniel
On 08/10/2017 07:59 PM, Matt Benjamin wrote:
I think the particular
On 8/11/17 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 on the customer system!
There are 2 duplicated fd indexed trees, not well coordinated.
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 late
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
wrote:
> On 8/11/1
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 timeframe
44 matches
Mail list logo