Re: [Nfs-ganesha-devel] chunk/dirent LRU memory management first pass pushed

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: >

Re: [Nfs-ganesha-devel] revert/repair ntirpc patch b4254b92

Hi Bill, Here's a thought: why not spend more time doing useful work, and less time trying to find someone to blame for changed behavior your own work introduced. Matt - "William Allen Simpson" wrote: > Last week, Daniel G had to revert one of my

Re: [Nfs-ganesha-devel] Deepsea support for NFS-Ganesha

Very nice, thanks folks. Matt - "Supriti Singh" wrote: > Hello all, > > As I said in the concall this week, at SUSE, we are working on > salt-based deployment system for ceph, called Deepsea. > https://github.com/SUSE/DeepSea > > Recently we added support to

Re: [Nfs-ganesha-devel] ganesha-2.4.1 + RGW FSAL + Ceph Jewel

Hi Karol, - "Karol Mroz" <km...@suse.de> wrote: > Hi Matt, > > Thanks for the input. Please see inline. > > On Sun, Nov 27, 2016 at 10:58:34PM -0500, Matt W. Benjamin wrote: > [...] > > > 1. `echo` or `touch` a new file > > > >

Re: [Nfs-ganesha-devel] ntirpc now has master and next branches

Hi Bill, Ok, thanks for the heads up, I at least do support this change. Matt - "William Allen Simpson" wrote: > Today, there was a small mixup on pulls. Malahal's was added to > duplex-13, while mine were added to duplex-14. > > After consultation with

Re: [Nfs-ganesha-devel] ganesha-2.4.1 + RGW FSAL + Ceph Jewel

Hi Karol, - "Karol Mroz" wrote: > Hi Ganesha developers, > > I've been playing with the RGW FSAL (ganesha-2.4.1) on a fairly > recent > Jewel-based (10.2.3-493-gb4c314a) Ceph cluster and wanted to share > some > observations. > > In a read-only scenario, the FSAL appears to

Re: [Nfs-ganesha-devel] Pros and cons of setting high/low on Dispatch_Max_Reqs_Xprt?

Hi, - "Akira Hayakawa" wrote: > Dispatch_Max_Reqs_Xprt is settable attribute that affects > stalling the ganesha server when the outstanding requests in the > queue > supersedes the set value. The default value is 512 and can take 1 to > 2048. > Ganesha unstalls the

Re: [Nfs-ganesha-devel] [ntirpc] refcount issue ?

Hi Swen, Yes, please do. Matt - "Swen Schillig" wrote: > On Mo, 2016-10-10 at 11:46 -0400, Matt Benjamin wrote: > > Hi Swen, > > > > Are you going to re-push your recent closed PR as 2 new PRs as > > planned? > > > > Dan has made some time this week to review and test,

Re: [Nfs-ganesha-devel] [PATCH] Fix refcount leak in svc_rpc_gss_data under RPCSEC_GSS_DESTROY

Hi Malahal, Is this intended to be a PR? Matt - "Malahal Naineni" wrote: > A umount/mount loop for a krb5 mount was sending RPCSEC_GSS_DESTROY > calls at times. We end up a huge number of contexts that are expired > but > not destroyed, eventually failing mounts after

Re: [Nfs-ganesha-devel] [PATCH] Fix refcount leak in svc_rpc_gss_data under RPCSEC_GSS_DESTROY

Oh, it is. Matt - "Matt W. Benjamin" <m...@cohortfs.com> wrote: > Hi Malahal, > > Is this intended to be a PR? > > Matt > > - "Malahal Naineni" <mala...@us.ibm.com> wrote: > > > A umount/mount loop for a krb5 mount was s

Re: [Nfs-ganesha-devel] Help!!! nfs client can't see any buckets when client mount on nfs-ganesha rgw

Hi, I don't notice anything offhand. If mount succeeded, the most likely thing is that the Access Key you've used can't see them. Can you create new buckets/objects? Matt - "yiming xie" wrote: > env :centos7, nfs-ganesha 2.3, jewel > nfs server ：192.168.77.61 >

Re: [Nfs-ganesha-devel] Ready for Matt's c++ patches and then tag V2.4.0!

I rebased yesterday--is there more to do? Matt - "Frank Filz" wrote: > Matt, Could you rebase and submit your c++ compile patches? > > Assuming nothing crashes and burns, I will merge those and tag V2.4.0 > by > tomorrow afternoon. > > On the concall, we

Re: [Nfs-ganesha-devel] pre-merge for V2.4-rc6

Hi Frank, I couldn't push your branch to gerrit due to it being ahead and having some illegal email wrt my account. However, it's pushed to the linuxbox2 nfs-ganesha repo, as branch rebase-c++. thanks! Matt - "Frank Filz" wrote: > I have posted a pre-merge for

Re: [Nfs-ganesha-devel] No merge this week - and entering rc phase

Sounds good, thanks Frank! Matt - "Frank Filz" wrote: > Sorry, with a short week for vacation yesterday and today, I ran out > of time > to get a merge out. Will shoot for a merge Monday. > > And that merge will be rc1. This primarily is a statement that we are >

Re: [Nfs-ganesha-devel] FSAL locks implementation

inline - "Frank Filz" wrote: > From: kanishk rastogi [mailto:kanishk...@gmail.com] > Sent: Tuesday, July 26, 2016 10:22 PM > To: Frank Filz > Cc: Soumya Koduri ; > nfs-ganesha-devel@lists.sourceforge.net > Subject: Re:

Re: [Nfs-ganesha-devel] multi-fd

VFS? Matt - "Marc Eshel" wrote: > Do we have an FSAL that implemented multi-fd ? > > > > From: "Frank Filz" > To: Marc Eshel/Almaden/IBM@IBMUS > Cc: > Date: 07/25/2016 04:10 PM > Subject:

Re: [Nfs-ganesha-devel] Announce Push of V2.4-dev-26

:) - "Marc Eshel" wrote: > We are making progress, now we return the file layout attribute >197.618970099 9141 TRACE_GANESHA: [work-65] > nfs4_FSALattr_To_Fattr > :NFS4 :F_DBG :Encoded attr 62, name = FATTR4_FS_LAYOUT_TYPES > > but we fail on the first layout get >

Re: [Nfs-ganesha-devel] Remove attributes from fsal_obj_handle, copy them out on create, and the Change attribute

++ 1. did you really mean you think it should always be based on ctim? 2. we should probably allow FSAL's to override Ganesha's default mtime behavior, e.g., for AFS or DCE every vnode has a monotonically increasing version number (that's called out in RFC5661 or an errata by David Noveck, I

Re: [Nfs-ganesha-devel] Challenges with FSAL_MDCACHE

Hi Frank, - "Frank Filz" wrote: > As I am digging more into what actually happens with FSAL_MDCACHE, I > am > finding some structural issues that are probably best resolved by > hastening > the migration to the support_ex (multiple-fd) API. > > The biggest issue

Re: [Nfs-ganesha-devel] Ganesha tcp tuning question.

Hi Malahal, IIRC, we're -mostly- relying on environmental settings. Improvements welcome. Matt - "Malahal Naineni" wrote: > We seem to have some network (tcp/ip) related issues, one of the guys > asked "Does Ganesha use tcp autotuning? Or fixed buffer?". Does > anyone

Re: [Nfs-ganesha-devel] Topic for discussion - Out of Memory Handling

I think this is probably the best approach for now, ++. Matt - "Frank Filz" wrote: > From: Swen Schillig [mailto:s...@vnet.ibm.com] > > Regardless of what's decided on how to react to out of mem > conditions, we > > must check and detect them, fast and reliable,

Re: [Nfs-ganesha-devel] Announce Push of V2.3-rc5

Hi, - "William Allen Simpson" wrote: > Updated to today's ganesha V2.3-rc5. > > Frank, could you please change nfs-ganesha/ntirpc to default > branch duplex-12? Matt forgot, and I've reminded him twice. Ok, fine, I've done this. I don't think this was a

Re: [Nfs-ganesha-devel] Missing files from directory with large entries

Hi Malahal, I'll send something in the next week or so. Matt - "Malahal Naineni" wrote: > This is an old email but any progress on this? > > Regards, Malahal. > > Frank Filz [ffilz...@mindspring.com] wrote: > >Hmm, that looks like a constant that needs to be

Re: [Nfs-ganesha-devel] [PATCH v2] ntirpc: implement setting CPU affinity of sender threads

Hi, I think we're not staying completely on-point. I agree with Wei's suggestion that different transports likely need different affinity strategies, and presumably you do too. There is probably no big issue with affinity syscalls--we should not do them inline with work, but different pools

Re: [Nfs-ganesha-devel] Is the Export ID visible to NFS clients?

Hi Dirk, Yes, Ganesha creates an expanded handle from your FSAL private handle and its own steering data. See the logic in support/nfs_filehandle_mgmt_c. Matt - "Dirk Jagdmann" wrote: > > The exportid is not meaningful to the client, however, since it is > part of > >

Re: [Nfs-ganesha-devel] [PATCH] ntirpc: remove redundant assignment of ->warnx

Hi, The svc_init() call is intended to precede any call to tirpc_control, and we do want this call to default-initialize. Regards, Matt - fangw...@huawei.com wrote: > From: Wei Fang > > ->warnx has been assigned defaultly. If we assigned here when > SVC_INIT_WARNX

Re: [Nfs-ganesha-devel] rc2 staged

Hi, If we permit conditional linkage against a static libntirpc, I would strongly prefer that it be explicit (config option that defaults to OFF). I don't think static linkage actually adds much to ease of use, since everybody should understand platform rules for shlibs. Matt - "Daniel

Re: [Nfs-ganesha-devel] Lost wakeup with nfs_rpc_dequeue_req() and nfs_rpc_enqueue_req()

>From memory. The code isn't trying to eliminate that race, no. If/when it arises, and all threads are idle, then the timeout will ensure progress. In particular, if there is no work for -any- threads, it is desirable for at least most to go idle. As work ramps up, threads will be woken. The

Re: [Nfs-ganesha-devel] Lost wakeup with nfs_rpc_dequeue_req() and nfs_rpc_enqueue_req()

I'm not sure I believe that there is hang case, but if there is, the simple fix for it is to bound the offending wait. I have a branch that uses a lock-free bounded mpmc queue based work we did last year in the Ceph codebase. I have something working but not efficiently, and I haven't have time

Re: [Nfs-ganesha-devel] Fridge worker pool to ntirpc?

Hi, inline - "Malahal Naineni" wrote: > > perf record shows that too much time is spent in malloc/free > functions. > Reported functions are alloc_nfs_request, alloc_nfs_res, and few > objects > in src/xdr_ioq.c file. alloc_nfs_res seems thread specific, so could > be

Re: [Nfs-ganesha-devel] event channel rbtree over-caching

Bill, Please don't make this change. We can discuss tuning changes at your leisure. Thanks, Matt - William Allen Simpson william.allen.simp...@gmail.com wrote: As I've been fixing the problem with ntirpc *_cleanup(), have discovered that it all passes through ntirpc svc_rqst.[ch].

Re: [Nfs-ganesha-devel] [PATCH] pool-n_threads should be decremented with mutex

Summarizing from call. Presumably we'd normally fix this without taking larger reorganization changes from duplex-12, but IIRC, there's a larger list of things, and we agreed to bring a list to the next call for discussion. Matt - William Allen Simpson william.allen.simp...@gmail.com

Re: [Nfs-ganesha-devel] clnt_vc_geterr() accessing freed memory

Hi, So this is all happening in clnt_vc_call()? I'll have a look at it. Matt - Malahal Naineni mala...@us.ibm.com wrote: Hi All, valgrind reported that clnt_vc_geterr() is accessing freed memory. Code review shows that nlm_send_async() calls clnt_call() and then calls

Re: [Nfs-ganesha-devel] DISCUSSION: V2.3 workflow and how we proceed

Hi, There clearly are people who think reviewing something large in small chunks is categorically easier, but, I don't completely understand the reasoning. 1) It seems to me that whether the small chunks are easier to actually understand, depends on whether the chunks can really be understood in

Re: [Nfs-ganesha-devel] DISCUSSION: V2.3 workflow and how we proceed

Hi, - GerritForge Support supp...@gerritforge.com wrote: From what I can tell, Frank finds problematic 1) a lack in gerrit of a changeset concept, plus, apparently It actually exists and is called “topic”. It will be very soon possible as well to merge a whole topic atomically