Re: [Nfs-ganesha-devel] Crash when running ls

2016-04-12 Thread William Allen Simpson
On 4/11/16 11:51 AM, Frank Filz wrote: >> Thanks to all replies on this thread. >> >> Initially, we had developed our FSAL based on Ganesha 2.1 but later moved >> to 2.2 when we noticed that 2.1 binaries were not available. >> However, when moving to 2.2 we noticed that there were changes in the >>

Re: [Nfs-ganesha-devel] Issue with readdir cache in VFS

2016-04-12 Thread Matt Benjamin
Hi Steve, Following up on your problem report: can you confirm the version and other specifics of the Ganesha environment where you are seeing this? - Original Message - > From: "steve landiss" > To: nfs-ganesha-devel@lists.sourceforge.net, > nfs-ganesha-supp...@lists.sourceforge.net

Re: [Nfs-ganesha-devel] out of memory issue in nfsv 2.3 package

2016-04-12 Thread Malahal Naineni
Kumar, DeepakX X [deepakx.x.ku...@intel.com] wrote: >Hi , >I am getting out of memory issue in nfsv4 protocol in nfs ganesha verstio >2.3. IN nfsv3 protocol we did not observe such issue at that particular >amount of upload. We are suspecting that packet consumption speed is >sl

Re: [Nfs-ganesha-devel] NFSv4 open close operations are slow compared to Linux kernel NFSv4

2016-04-12 Thread Malahal Naineni
Tushar Shinde [mtk.tus...@gmail.com] wrote: > I had used async with kernel and NFS_Commit = FALSE; with Ganesha. > Do you think still it will be unfair comparison? Usually NFS clients are smart and they send write with FILE_SYNC if they don't have any more writes. There are some clients (VMware I

Re: [Nfs-ganesha-devel] Crash when running ls

2016-04-12 Thread Malahal Naineni
Varghese Devassy [v_deva...@yahoo.com] wrote: > Thanks to all replies on this thread. > > Initially, we had developed our FSAL based on Ganesha 2.1 but later > moved to 2.2 when we noticed that 2.1 binaries were not available. > However, when moving to 2.2 we noticed that there were changes in t

[Nfs-ganesha-devel] V2.3-stable/V2.3.2 content request

2016-04-12 Thread Malahal Naineni
Hi All, Jiffin requested d7afb5c9cf5d1d2c6f425cdf300027f6ef30ce0f, so I will add it to V2.3.2 release. Planning to release it by the end of this week(end). If you have anything that you would like to see in V2.3.2 release, please let me know. Regards, Malahal. -

Re: [Nfs-ganesha-devel] Crash when running ls

2016-04-12 Thread Varghese Devassy
I am moving to 2.3 very soon. In the meantime, I searched for the latest 2.3 binary and source package and I see some of them at rpmfind.net. The latest version I see here is 2.3.1.4 (nfs-ganesha-2.3.1-4.el7.x86_64.rpm

[Nfs-ganesha-devel] Announce Push of V2.4-dev-15

2016-04-12 Thread Frank Filz
Branch next Tag:V2.4-dev-15 Release Highlights * FSAL_RGW fixes * fix a couple export permission issues * rename EXPORT_OPTION_ACCESS_TYPE to EXPORT_OPTION_ACCESS_MASK Signed-off-by: Frank S. Filz Contents: 7e15ee6 Frank S. Filz V2.4-dev-15 ca6fac5 Malahal Naineni Change EXPORT_OPTION_ACCE

[Nfs-ganesha-devel] A useful gerrithub tip

2016-04-12 Thread Frank Filz
If you are working on a complex patch set that will need several reviews, and you have to rebase it to the latest dev, AND you want to make updates to the patch set in response to review comments: Do two separate pushes to gerrit. That way, when a reviewer looks at the diff between versions of a pa

[Nfs-ganesha-devel] rgw commits for 2.3.2: was: Announce Push of V2.4-dev-15

2016-04-12 Thread Matt Benjamin
Hi Malahal, Here's the list of FSAL_RGW commits, including the ones just merged to next. Regards, Matt commit 929264561cf83826dbe93dee0e2ea14ee5fc64ba Author: Matt Benjamin Date: Sun Mar 27 15:45:30 2016 -0400 rgw: flags cleanup Remove missed uses of 0 as a flag. Chang

Re: [Nfs-ganesha-devel] out of memory issue in nfsv 2.3 package

2016-04-12 Thread Kumar, DeepakX X
Hi , Thanks for responding . We have 16 worker thread configured in our system. We tried to take further new version but due to several issues , we had to retract . Also it is worth noting that when we try to slow down enqueue operation , issue does not occur or occurs very late. Further we c