Agree, existing retire logic in dupreq_finish will not be changed. In
addition to this, stale drc objects will be handled in the timeout
function. Stale drc objects are drcs which aren't referenced in a
while (maintain last_used timestamp in drc and update it on every
ref). This stale drc can have
Matt, you are correct. We lose some memory (drc and dupreqs) for a client
that never reconnects. Doing solely time based strategy is not scalable as
well unless we fork multiple threads for doing this. My understanding is
that there will be one time based strategy (hopefully, the time is long
enoug
There is one drc lock for the entire channel but you can have configurable
number of partitions per a channel (aka socket). In other words, it is easy
to fix a partition lock if it is gets contentious (just increase the number
of partitions), but lot harder with drc lock. I imagine, this is the rea
>From Frank Filz :
Frank Filz has uploaded this change for review. (
https://review.gerrithub.io/359513
Change subject: Use saved_export when cleaning up saved_object (SavedFH).
..
Use saved_export when cleaning up saved_objec
Hi Guys,
To get on the record here, the current retire strategy using new requests to
retire old ones is an intrinsic good, particularly with TCP and related
cots-ord transports where requests are totally ordered. I don't think moving
to a strictly time-based strategy is preferable. Apparentl
>From Frank Filz :
Frank Filz has uploaded this change for review. (
https://review.gerrithub.io/359509
Change subject: Fix infinite loop in avl_dirent_set_deleted
..
Fix infinite loop in avl_dirent_set_deleted
Instead of con
I don't see a complete design proposal here. Can you clarify the fuller
picture of what you're proposing to do?
Matt
- Original Message -
> From: "Satya Prakash GS"
> To: "Matt Benjamin" , "Malahal Naineni"
> ,
> nfs-ganesha-devel@lists.sourceforge.net
> Sent: Wednesday, May 3, 2017 4
Thank you for the quick reply.
In dupreq_finish, as part of retiring the drc quite a few locks are
acquired and dropped (per entry). I want to fix a bug where drc retire
will happen as part of a different function (this will be called from
free_expired). The existing logic gets carried over to the
Hi Satya,
Sorry, my recommendation would be, we do not change locking to be more coarse
grained, and in general, should update it in response to an indication that it
is incorrect, not to improve readability in the first instance.
Regards,
Matt
- Original Message -
> From: "Matt Benja
No?
Matt
- Original Message -
> From: "Satya Prakash GS"
> To: nfs-ganesha-devel@lists.sourceforge.net, "Malahal Naineni"
>
> Sent: Wednesday, May 3, 2017 3:34:31 PM
> Subject: [Nfs-ganesha-devel] reg. drc nested locks
>
> Hi,
>
> In nfs_dupreq_start and nfs_dupreq_finish when alloca
Hi,
In nfs_dupreq_start and nfs_dupreq_finish when allocating/freeing a
dupreq_entry we are trying hard to keep both dupreq_q and the rbtree
in sync acquiring both the partition lock and the drc (t->mtx,
drc->mtx). This requires dropping and reacquiring locks at certain
places. Can these nested lo
11 matches
Mail list logo
