Re: [Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Ensure partition lock and qlane lock ordering

Hi Dan, This change could lead to a thread trying to acquire qlock while holding the same(see below). The *lock_already_held* flag is now removed. #2 0x7faf71f7dc08 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x005227c0 in _mdcache_lru_unref (entry=0x7faee0dbe100,

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Revert "CMake - Have 'make dist' generate the correct tarbal...

>From : william.allen.simp...@gmail.com has uploaded this change for review. ( https://review.gerrithub.io/373160 Change subject: Revert "CMake - Have 'make dist' generate the correct tarball name"

Re: [Nfs-ganesha-devel] NFSv4 delegation in Ganesha

On 8/7/17 2:29 AM, Soumya Koduri wrote: clubbing with lock, a dedicated fop Amusing India'isms? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org!

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Fix issues with ntirpc in generated tarball

>From Daniel Gryniewicz : Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/373093 Change subject: Fix issues with ntirpc in generated tarball .. Fix issues with ntirpc in

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Ensure partition lock and qlane lock ordering

>From Daniel Gryniewicz : Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/373094 Change subject: Ensure partition lock and qlane lock ordering .. Ensure partition lock and

Re: [Nfs-ganesha-devel] V4 nested export path issue

> Frank, Dan. > > Consider the following situation. > > There are 2 configured exports > > exp_id = 10 > Path = /gpfs0/V4 > Pseudo = /gpfs0/V4 > > > exp_id = 20 > Path = /gpfs0/V4/Tom > Pseudo = /gpfs0/V4/Tom > > Client A is allowed to access export ID 20 but is not allowed to access

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

> It never has been. In cache_inode, a pin-ref kept it from being reaped, now > any ref beyond 1 keeps it. Guess we need to do something about that... We need to put limits on state somewhere, that would take care of it mostly. We could still have some files in excess of high water mark due to

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

It never has been. In cache_inode, a pin-ref kept it from being reaped, now any ref beyond 1 keeps it. On Fri, Aug 4, 2017 at 1:31 PM, Frank Filz wrote: >> I'm hitting a case where mdcache keeps growing well beyond the high water >> mark. Here is a snapshot of the

[Nfs-ganesha-devel] V4 nested export path issue

Frank, Dan. Consider the following situation. There are 2 configured exports exp_id = 10 Path = /gpfs0/V4 Pseudo = /gpfs0/V4 exp_id = 20 Path = /gpfs0/V4/Tom Pseudo = /gpfs0/V4/Tom Client A is allowed to access export ID 20  but is not allowed to access export ID 10. When trying to mount

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: WIP: Delegation support for FSAL_GLUSTER

>From Soumya : Soumya has uploaded this change for review. ( https://review.gerrithub.io/372998 Change subject: WIP: Delegation support for FSAL_GLUSTER .. WIP: Delegation support for FSAL_GLUSTER Intial

Re: [Nfs-ganesha-devel] NFSv4 delegation in Ganesha

On 08/03/2017 08:42 PM, Jeff Layton wrote: On Fri, 2017-05-19 at 11:55 +0530, Soumya Koduri wrote: Hi, On 05/18/2017 08:04 PM, Yun-Chih Chen wrote: Hi, friends: I'm studying the affect of NFSv4 on Linux. As far as I know, NFS implemented in Linux kernel supports read delegation but not

Re: [Nfs-ganesha-devel] mdcache growing beyond limits.

On 8/7/17 9:42 AM, Frank Filz wrote: It never has been. In cache_inode, a pin-ref kept it from being reaped, now any ref beyond 1 keeps it. Guess we need to do something about that... We need to put limits on state somewhere, that would take care of it mostly. We could still have some files