Yea that was what I assumed but that part seems to have got tangled up with the
fd recovery. We need to rework the fd recovery anyway. Maybe another 2.6 item.
And then we can make a proper gradual demotion to L2.
Frank
Sent from my iPhone
> On Apr 6, 2017, at 5:10 PM, Matt W. Benjamin wrote:
Hi Frank,
Entries were supposed to gradually move to L2 independent of any other
process--the only connection was intended to be that the L1 -> L2 transition
might induce other compaction, hints, etc as a side effect.
Matt
- "Frank Filz" wrote:
> Take a look:
>
> https://review.gerrithu
Take a look:
https://review.gerrithub.io/356041
It's not complete, and not tested, but it's at least something to look at
and discuss.
I do have one question about the lru run thread. For mdcache entries, it's
running seems dependent on open file descriptors, not number of mdcache
entries in use
>From Frank Filz :
Frank Filz has uploaded this change for review. (
https://review.gerrithub.io/356041
Change subject: WIP - Dirent/chunk LRU memory management
..
WIP - Dirent/chunk LRU memory management
Here is a first pass
The longevity cluster has been updated to glusterfs-3.10.1 (from 3.8.5).
General information on the longevity cluster is at [1].
In the previous update sharding was enabled on the gluster volume. This
time I have added a NFS-Ganesha NFS server on one server. Its memory
usage is being sampled a
