[Nfs-ganesha-devel] Request clarification on mdcache_readdir_chunked()

Hi Frank, While I was scanning through readdir code path I noticed that we do create cache entry for each of the dirent (if not present) in the chunk as part of cbk - "mdc_readdir_chunked_cb()". But there is a repetitive check right after that (in "mdcache_readdir_chunked()") to verify if all

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

Hi All, I have fixed earlier delegation code-path to an extent and pushed the patches to gerrit [1] now. Please take a look and let me know if there is anything missing or not right. The code needs a lot of cleanup but from my initial tests I could see READ/WRITE delegations being granted an

Re: [Nfs-ganesha-devel] Recommended stable release for NFS-Ganesha

On 09/15/2017 02:30 AM, Madhu Venugopal wrote: Hi, I am writing to enquire about the recommended stable release for NFS-Ganesha. I see that 2.5.2 is out on https://github.com/nfs-ganesha/nfs-ganesha/releases. But the wiki page at https://github.com/nfs-ganesha/nfs-ganesha/wiki only talks ab

Re: [Nfs-ganesha-devel] cthon04 tests in the CentOS CI uses the deprecated/removed create-export-ganesha.sh script

On 09/28/2017 01:15 AM, Niels de Vos wrote: Hi Soumya and Arthy, The GlusterFS 3.12 release is now the standard version that gets installed for CentOS users. We already identified a regression (related to the 'gluster volume create ... force' command), and an emergency update is being pushed t

Re: [Nfs-ganesha-devel] cthon04 tests in the CentOS CI uses the deprecated/removed create-export-ganesha.sh script

On 09/29/2017 03:35 PM, Niels de Vos wrote: On Fri, Sep 29, 2017 at 03:06:39PM +0530, Soumya Koduri wrote: On 09/28/2017 01:15 AM, Niels de Vos wrote: Hi Soumya and Arthy, The GlusterFS 3.12 release is now the standard version that gets installed for CentOS users. We already identified a

Re: [Nfs-ganesha-devel] V2.5-stable maintenance

Hi Malahal, On 10/05/2017 09:06 AM, Malahal Naineni wrote: 85bd9217d GLUSTER: make sure to free xstat when meeting error Before applying the above patch, I request to backport below commit as well - 39119aa FSAL_GLUSTER: Use glfs_xreaddirplus_r for readdir Thanks, Soumya

Re: [Nfs-ganesha-devel] V2.5-stable maintenance

, Malahal. On Thu, Oct 5, 2017 at 8:32 PM, Soumya Koduri <mailto:skod...@redhat.com>> wrote: Hi Malahal, On 10/05/2017 09:06 AM, Malahal Naineni wrote: 85bd9217d GLUSTER: make sure to free xstat when meeting error Before applying the above patch, I request to backp

Re: [Nfs-ganesha-devel] UID and GID mapping

Anonymous_uid & Anonymous_gid options can used in EXPORT {} block to set anonuid/anongid [1] Thanks, Soumya [1] https://github.com/nfs-ganesha/nfs-ganesha/blob/next/src/config_samples/config.txt#L210 On 10/30/2017 09:43 PM, William Allen Simpson wrote: On 10/30/17 3:56 AM, Nitesh Sharma wro

Re: [Nfs-ganesha-devel] Backport list for 2.5.4

Please include below commits as well - commit f5c48022176a656143b28824c2fb913518bd8cc4 Author: Soumya Koduri Date: Thu Oct 26 12:22:38 2017 +0530 FSAL_GLUSTER: Use the new API to be able to set lkowner commit e03420fa445a0dac3e05c11f4718b6120744f1b5 Author: Kinglong Mee Date: Thu

Re: [Nfs-ganesha-devel] Crash in libntirpc with 1.6.3 version

This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org. There is similar crash (in 'svc_release_it') hit when rpc callback channel is used. Jiffin reported the same in github [1]. Somewhere in cbk paths probably, xprt->ref is not taken. Thanks, Soumya

Re: [Nfs-ganesha-devel] [Gluster-users] boot auto mount NFS-Ganesha exports failed

This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org. Hi, Since its working on your test machine, most likely could be NFS client-side issue. Please check if there are any kernel fixes between those versions which may have caused this. I see similar

Re: [Nfs-ganesha-devel] [Nfs-ganesha-support] Troubles with configuration

>>> # mount -o nfsvers=3 172.20.252.12:/ /mnt -v Looks like you are trying to mount "/" via v3. "/" is reserved for psuedo file system which can be mounted only via "v4" AFAIK. Please try using a different path other than '/' in your Export Block. >>> EXPORT >>> { >>> # Export Id

Re: [Nfs-ganesha-devel] Upcoming patch set to replace attrlist in fsal_obj_handle with pointer

patch URL with changes needed in FSAL_GLUSTER - https://github.com/soumyakoduri/nfs-ganesha/commit/920dac38464e975472eaa1771b02d58a01980f9a Thanks, Soumya On 05/28/2015 10:54 PM, Frank Filz wrote: > Folks, > > I would like to get all FSALs prepared with this before actually pushing > this in. >

[Nfs-ganesha-devel] pull request

Hi Frank, Request you to pull in FSAL_GLUSTER patch - https://review.gerrithub.io/#/c/236129 Thanks, Soumya -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.source

Re: [Nfs-ganesha-devel] [Gluster-users] Questions on ganesha HA and shared storage size

r machine where ganesha 2.1.0 is running I see tcp is used, not > tcp6. > Could it be that the RPC are always trying to use IPv6? That would be > wrong. > Thanks, > > Alessandro > > On Wed, 2015-06-10 at 15:28 +0530, Soumya Koduri wrote: >> >> O

Re: [Nfs-ganesha-devel] Another fsal_grace question

On 06/17/2015 08:44 PM, Malahal Naineni wrote: > Hi All, > > There was a mail Soumya posted a while back on fsal_grace. The original > patch that introduced fsal_grace seemed to pass everything to FSAL if > fsal_grace was true. Essentially it bypassed all grace checks in > ganesha, and passed the

Re: [Nfs-ganesha-devel] Problems in /usr/libexec/ganesha/dbus-send.sh and ganesha dbus interface when disabling exports from gluster

On 06/17/2015 10:57 PM, Alessandro De Salvo wrote: > Hi, > when disabling exports from gluster 3.7.1, by using gluster vol set > ganesha.enable off, I always get the following error: > > Error: Dynamic export addition/deletion failed. Please see log file for > details > > This message is produ

[Nfs-ganesha-devel] Request to merge patches to V2.2-stable branch

Hi Kaleb/Malahal, Request you to merge below FSAL_GLUSTER patches into V2.2-stable branch - 366f71c - FSAL_GLUSTER: Fixed an issue with dereferencing a NULL ponter c4f33d6 - FSAL_GLUSTER : Improvements in acl feature b1df525 - FSAL_GLUSTER: Stop polling upcall events if not supported Thanks, Sou

Re: [Nfs-ganesha-devel] Request to merge patches to V2.2-stable branch

shall add more upcall events and may be an option to decide if upcall is required or not which may lead to multiple exit cases, I had thought it may be good to capture the return status of thread exit, if at all passed. > Regards, Malahal. > > Malahal Naineni [mala...@us.ibm.com] wrote:

Re: [Nfs-ganesha-devel] Problems in /usr/libexec/ganesha/dbus-send.sh and ganesha dbus interface when disabling exports from gluster

/rpmbuild/BUILD/nfs-ganesha-2.2.0-3-0.1.1-Source, built at Jun 15 2015 > 22:13:18 on node2 > 18/06/2015 16:20:49 : epoch 5582d3c1 : node2 : ganesha.nfsd-31956[main] main > :MAIN :EVENT :ganesha.nfsd Starting: Ganesha Version > /root/rpmbuild/BUILD/nfs-ganesha-2.2.0-3-0.1.1-Source,

Re: [Nfs-ganesha-devel] Request to merge patches to V2.2-stable branch

On 06/18/2015 10:35 AM, Malahal Naineni wrote: > Soumya Koduri [skod...@redhat.com] wrote: >> Right. But even on success, "retval" need not be set until the >> thread exits with a value other than NULL. >> >> From the manpage, >>>>> >>

Re: [Nfs-ganesha-devel] Problems in /usr/libexec/ganesha/dbus-send.sh and ganesha dbus interface when disabling exports from gluster

On 06/18/2015 07:39 PM, Malahal Naineni wrote: > I still have not looked at the log messages, but I see the dbus thread > waiting for the upcall thread to complete when an export is removed. Is > there is a time limit on how the upcall thread gets blocked? > A variable called 'destroy_mode' is us

Re: [Nfs-ganesha-devel] Request to merge patches to V2.2-stable branch

On 06/18/2015 10:33 PM, Malahal Naineni wrote: > Soumya Koduri [skod...@redhat.com] wrote: >> >> I thought pthread_exit() always returns a pointer which gets assigned to >> retval of pthread_join(). I assume this is the flow --> > > pthread_exit() does take a &quo

[Nfs-ganesha-devel] 'clustered' configuration parameter + use of nodeid

Hi, As we were discussing over #ganesha, currently 'clustered' mode mandates that each of the NFS-Ganesha servers is associated with a nodeid which may not be applicable for all the clustering solutions. We may choose to use IP_ADDR or hostnames to store persistent state information for each o

Re: [Nfs-ganesha-devel] 'clustered' configuration parameter + use of nodeid

On 06/24/2015 04:47 AM, Frank Filz wrote: >> As we were discussing over #ganesha, currently 'clustered' mode mandates >> that each of the NFS-Ganesha servers is associated with a nodeid which may >> not be applicable for all the clustering solutions. We may choose to use >> IP_ADDR or hostnames t

Re: [Nfs-ganesha-devel] 'clustered' configuration parameter + use of nodeid

Hi Frank/Malahal, Re-opening this thread. On 06/24/2015 04:47 AM, Frank Filz wrote: > Note that the way Ganesha handles the epoch for clientids is structured in a > way that Ganesha doesn't have to be party to the details. There is a command line option that allows and external actor (presum

Re: [Nfs-ganesha-devel] Multiple-fd work

With respect to FSAL_GLUSTER, like FSAL_GPFS, I think we can make use multiple-fd support (per OPEN) to support OPEN UPGRADE/OPEN_DOWNGRADE for specific NFS clients and to avoid the extra UNLOCK requests which you have mentioned at the end. I could have missed the context. Could you please spe

[Nfs-ganesha-devel] Provide NLM/NFSv4 client identifier to FSAL

Hi, As discussed over #ganesha, we are wondering if we can provide any identifier unique to each NFS client to FSAL so that it may/can help the backend filesystems to validate the reclaim lock requests. The use-case is to allow reclaim/replay of the lock requests by NFS clients after NFS-Ganes

Re: [Nfs-ganesha-devel] Provide NLM/NFSv4 client identifier to FSAL

work patches, shouldn't it? Just implement > the *2() versions of the FSAL API calls, and you will get a state with > each relevant call. > > Dan > > On Mon, Aug 31, 2015 at 2:34 AM, Soumya Koduri <mailto:skod...@redhat.com>> wrote: > > Hi, > >

Re: [Nfs-ganesha-devel] Provide NLM/NFSv4 client identifier to FSAL

On 09/01/2015 09:28 PM, Frank Filz wrote: >> Thanks for your inputs. >> >> On 08/31/2015 09:24 PM, Frank Filz wrote: >>> You could actually do this with the old interface if you support lock >>> owners. While the lock owner is defined in the FSAL as a void *, it is >>> in fact always a state_owne

Re: [Nfs-ganesha-devel] [Nfs-ganesha-support] Fwd: Ubuntu 14.04.3, Conflicting Types on Make

Joe, On Ubuntu, seems like you need to install "libacl1-dev" package to get the ACL libraries which is needed by FSAL_GLUSTER. Also note after installing the package, you need to re-compile both Gluster and nfs-ganesha sources to rightly link to this library. Thanks, Soumya On 09/04/2015 11:47

[Nfs-ganesha-devel] Default ports to be used by NFS side-band protocol services (lockd, statd, rquotad)

Hi, In the latest Linux distributions (Fedora), ports 2049 (nfs) and 20048 (mountd) are configured to be opened by default by firewalld service. Files: '/usr/lib/firewalld/services/nfs.xml' & '/usr/lib/firewalld/services/mountd.xml'. We would like to know what ports could be used by default fo

Re: [Nfs-ganesha-devel] Default ports to be used by NFS side-band protocol services (lockd, statd, rquotad)

On 09/15/2015 12:00 AM, Malahal Naineni wrote: > Steve Dickson [ste...@redhat.com] wrote: >> Hello, >> >> On 09/14/2015 09:11 AM, Soumya Koduri wrote: >>> Hi, >>> >>> In the latest Linux distributions (Fedora), ports 2049 (nfs) and 20048 >&g

Re: [Nfs-ganesha-devel] IP based recovery

Hi, There is already an IP-based recovery solution provided by nfs-ganesha (except for one small issue with the 'clustered' config option which I shall mention below) and yes, we are currently using the same for our HA cluster solution. By default, if not provided any event in the input to the

Re: [Nfs-ganesha-devel] IP based recovery

On 09/18/2015 10:44 AM, Soumya Koduri wrote: > Hi, > > There is already an IP-based recovery solution provided by nfs-ganesha > (except for one small issue with the 'clustered' config option which I > shall mention below) and yes, we are currently using the same for

Re: [Nfs-ganesha-devel] IP based recovery

On 09/18/2015 08:45 PM, Malahal Naineni wrote: > Soumya Koduri [skod...@redhat.com] wrote: >> The issue was with 'clustered' config option. If this option is set, >> nfs-ganesha writes the clients state to '/var/lib/nfs/ganesha/node{id}' >> directory. S

Re: [Nfs-ganesha-devel] IP based recovery

Hi Jeremy, On 09/19/2015 12:08 AM, Jeremy Bongio wrote: > How do the recovery directories work? > > I see in nfs4_create_recov_dir(void) that we create the top level > recovery directories and optionally a nodeid directory: > > err = mkdir(NFS_V4_RECOV_ROOT, 0755); > ... > snprintf(v4_recov_dir, s

Re: [Nfs-ganesha-devel] Need clarification on LAYOUTRECALL implementation

Hi Dan/Matt, In the recent LinuxCon Europe Conference, Christoph Hellwig has given a talk on "A Simple, and Scalable pNFS Server For Linux" [1] During that talk, he has mentioned that for kernel-NFS , LayoutRecall semantics & logic is same as DelegRecall (at least for block & object-type layou

Re: [Nfs-ganesha-devel] Need clarification on LAYOUTRECALL implementation

, telling the DSs that the I/O must be > blocked. So, we have to let the FSAL handle it. (Note, this would > also apply to blocklayout, if we had it; it's a property of the "p" in > pNFS). > > Dan > > On Tue, Oct 13, 2015 at 2:43 AM, Soumya Koduri wrote: >

[Nfs-ganesha-devel] nfs-ganesha helper services

Hi, As part of "https://review.gerrithub.io/#/c/250239/"; (& as per recent discussions we had over IRC), we are planning to define a helper service nfs-ganesha-epoch{.service} (similar) which shall invoke a script configured in '/etc/sysconfig/ganesha' as EPOCH_SCRIPT (default value : /bin/tru

[Nfs-ganesha-devel] TCP ACK not being sent

Hi, In a 2-node nfs-ganesha cluster setup, we have noticed that after couple of iterations of failover & failback of the IP between those nodes, client I/O gets stuck. We have observed this in RHEL 7.1 environments (not sure about RHEL 6). While debugging I see that, the node which takes over V

Re: [Nfs-ganesha-devel] TCP ACK not being sent

ailover/failback. Thanks, Soumya > > stijn > > On 11/06/2015 01:47 PM, Soumya Koduri wrote: >> Hi, >> >> In a 2-node nfs-ganesha cluster setup, we have noticed that after >> couple of iterations of failover & failback of the IP between those >> nodes, c

Re: [Nfs-ganesha-devel] TCP ACK not being sent

On 11/06/2015 06:57 PM, Niels de Vos wrote: > On Fri, Nov 06, 2015 at 07:47:35AM -0500, Soumya Koduri wrote: >> Hi, >> >> In a 2-node nfs-ganesha cluster setup, we have noticed that after >> couple of iterations of failover & failback of the IP between those >

[Nfs-ganesha-devel] FOPs to be blocked during grace

Hi, From the code looks looks like, we block the following FOPs while the NFS server is in grace (which have 'nfs_in_grace' check)- NFSv3 - SETATTR NLM - LOCK UNLOCK NFSv4 - OPEN LOCK REMOVE RENAME SETATTR Request clarification behind selecting these fops. Dan confirmed that 'as per 5661 RFC

Re: [Nfs-ganesha-devel] TCP ACK not being sent

On 11/10/2015 12:03 AM, Malahal Naineni wrote: > Soumya Koduri [skod...@redhat.com] wrote: >> >> >> On 11/06/2015 06:57 PM, Niels de Vos wrote: >>> On Fri, Nov 06, 2015 at 07:47:35AM -0500, Soumya Koduri wrote: >>>> Hi, >>>> >>>>

Re: [Nfs-ganesha-devel] FOPs to be blocked during grace

On 11/10/2015 01:50 AM, J. Bruce Fields wrote: > On Mon, Nov 09, 2015 at 09:36:03PM +0530, Soumya Koduri wrote: >> Hi, >> >> From the code looks looks like, we block the following FOPs while the >> NFS server is in grace (which have 'nfs_in_grace' check

Re: [Nfs-ganesha-devel] FOPs to be blocked during grace

Thanks for your inputs. Response inline - On 11/10/2015 02:21 AM, Frank Filz wrote: > From: Malahal Naineni [mailto:mala...@us.ibm.com] >> Soumya Koduri [skod...@redhat.com] wrote: >>> Hi, >>> >>> From the code looks looks like, we block the following FOPs

Re: [Nfs-ganesha-devel] FOPs to be blocked during grace

On 11/10/2015 08:21 PM, J. Bruce Fields wrote: > On Tue, Nov 10, 2015 at 05:13:53PM +0530, Soumya Koduri wrote: >> >> >> On 11/10/2015 01:50 AM, J. Bruce Fields wrote: >>> On Mon, Nov 09, 2015 at 09:36:03PM +0530, Soumya Koduri wrote: >>>> Hi, >>&g

Re: [Nfs-ganesha-devel] pNFS documentation

On 12/22/2015 06:48 AM, Gmail wrote: > Hello All, > > Is there any documentation describing how does pNFS works in NFS-Ganesha? > > I’ve done a simple setup with 3 Gluster storage nodes and two clients, > NFS-Ganesha is running on the three storage nodes, the Gluster volume is > configured in dis

Re: [Nfs-ganesha-devel] Patches that need back port from V2.4 to V2.3

7bfed52aaa0f2f0a3d89cde > Author: Matt Benjamin > > FSAL_CEPH: NUL-terminate symlink buffers > > > commit e4d51915b3fbdc06212777819c879be77d5cfff7 > Author: Soumya Koduri > > service files: Helper service to pre-process config options > > > commit 020e

[Nfs-ganesha-devel] Cache inode entries marked 'LRU_ENTRY_CLEANUP'

Hi, In cache_inode_unexport(), if we encounter an entry marked 'LRU_ENTRY_CLEANUP', we ignore it and continue. status = cache_inode_lru_ref(entry, LRU_FLAG_NONE); if (status != CACHE_INODE_SUCCESS) { /* This entry was going stale, skip it. */ PTHREAD_RWLOCK_unlock(&export

Re: [Nfs-ganesha-devel] Cache inode entries marked 'LRU_ENTRY_CLEANUP'

okup table"--or 0 when > all >> refs are returned, and only then briefly before being destroyed. >>> >>> We should probably review all the workflows the involve the cleanup >> queue, and discuss whether they are fully coherent. It seems possible > that >>

Re: [Nfs-ganesha-devel] [ISSUE] nfs-mon resource errors

Hi Christian, On 02/06/2016 03:04 AM, Christian Petersen wrote: > Hey guys, > > My setup is as follows. > > ·ESXi and vCenter with 3 virtual machines running CentOS 7 > > osolid state VMFS volumes attached > > ·GlusterFS > > ·3 active nodes making up a replicated volume > > ·NFS-Ganesha > > ·PCS/P

[Nfs-ganesha-devel] SIGSEGV in "xdr_nfs_fh3()"

Hi Matt/Daniel, There is a crash reported due to SIGSEGV in "xdr_nfs_fh3()" [1]. As mentioned in the comments [2], we couldn't analyze the core, but when inspected the code, found a potential issue. In 'xdr_nfs_fh3(..)' { . 458 if (!xdr_bytes 459 (xdrs, (char **)&ob

Re: [Nfs-ganesha-devel] SIGSEGV in "xdr_nfs_fh3()"

mean. > Thanks Matt. So can the fix be to return false when nodesize is '0'? -Soumya > Matt > > - Original Message - >> From: "Soumya Koduri" >> To: "Matt W. Benjamin" , "Daniel Gryniewicz" >> >> Cc: nfs-gan

Re: [Nfs-ganesha-devel] nfs-ganesha crash!

Hi, Can you please provide core (or at least bt)? Also please check '/var/log/ganesha.log' and '/var/log/ganesha-gfapi.log' for any errors. Thanks, Soumya On 04/06/2016 05:48 PM, zhw bai wrote: > @all > my nfs-ganesha crashed when I do my test, anyone can help? thank > you in advance.' > >

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

Hi, I had run into similar crash when cache inode entries get reaped. Below patch had fixed the issue. https://review.gerrithub.io/#/c/258687/ I think this patch is not merged into V2.2. Please check nfs-ganesha-2.3 or current next branch packages. Thanks, Soumya On 04/09/2016 05:54 AM, Varg

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

On 04/10/2016 07:53 AM, steve landiss wrote: > Thanks Mat!t... Where can I see an example of how Gluster is > invalidating the upcalls? You could refer to "src/FSAL/FSAL_GLUSTER/fsal_up.c" for upcall routines used by Gluster. > > And how would I bound the time to restat to 0? Where is that set

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

com > > On 2016-04-10 06:40 AM, Soumya Koduri wrote: >> Hi, >> >> I had run into similar crash when cache inode entries get reaped. >> Below patch had fixed the issue. >> >> https://review.gerrithub.io/#/c/258687/ >> >> I think this patch is not

Re: [Nfs-ganesha-devel] How to build v2.3.2

Hi Serkan, I see V2.3.2 tag when I checkout to V2.3-stable branch. Are you using latest sources? Alternatively you could checkout to a branch using tag as well. # git checkout -b V2.3.2 V2.3.2 M src/libntirpc Switched to a new branch 'V2.3.2' # git describe V2.3.2 # git checkout -b V2.3-

Re: [Nfs-ganesha-devel] Question on cache_inode_remove

Hi Frank/Matt, Reviving the below thread. Since we seem to agree that we should discard the entry if the link count is 1 instead of trying to refresh the attributes, I have made the relevant changes. Kindly review the same. Patch: https://review.gerrithub.io/#/c/273611/ Thanks, Soumya On 07/

[Nfs-ganesha-devel] Any FSAL not using 'fsal_obj_handle->attrs->numlinks' ?

that its value is being queried in 'cache_inode_close()' as well. But still would like to confirm it. Thanks, Soumya [1] https://review.gerrithub.io/#/c/273611/3 On 04/20/2016 02:27 PM, Soumya Koduri wrote: > Hi Frank/Matt, > > Reviving the below thread. Since we seem to agree

Re: [Nfs-ganesha-devel] Ganesha 2.3.0 crash issue

Hi Krishna, yes. We had been reported similar issue earlier and Frank submitted a patch to fix it [1]. I think the fix is available in V2.3.1 or later branches. Thanks, Soumya [1] https://review.gerrithub.io/#/c/263358/ On 04/29/2016 07:09 AM, Krishna Harathi wrote: > Hi, > > We are using Gan

Re: [Nfs-ganesha-devel] Ganesha 2.3.0 crash issue

Hi Malahal, On 05/04/2016 07:37 PM, Malahal Naineni wrote: > Soumya Koduri [skod...@redhat.com] wrote: >> Hi Krishna, >> >> yes. We had been reported similar issue earlier and Frank submitted a >> patch to fix it [1]. I think the fix is available in V2.3.1 or late

Re: [Nfs-ganesha-devel] Ganesha 2.3.0 crash issue

On 05/04/2016 08:30 PM, Soumya Koduri wrote: > Hi Malahal, > > On 05/04/2016 07:37 PM, Malahal Naineni wrote: >> Soumya Koduri [skod...@redhat.com] wrote: >>> Hi Krishna, >>> >>> yes. We had been reported similar issue earlier and Frank submitted a &

Re: [Nfs-ganesha-devel] Cache inode entries marked 'LRU_ENTRY_CLEANUP'

Hi Dan, Reviving this old thread. On 02/02/2016 07:44 PM, Daniel Gryniewicz wrote: > On 02/02/2016 05:34 AM, Soumya Koduri wrote: >> Thank you all for your inputs. I shall check if there is any easy way of >> re-producing it and then test with Daniel's patch added. > >

Re: [Nfs-ganesha-devel] Cache inode entries marked 'LRU_ENTRY_CLEANUP'

On 05/18/2016 08:24 PM, Daniel Gryniewicz wrote: > On 05/18/2016 10:19 AM, Soumya Koduri wrote: >> Hi Dan, >> >> Reviving this old thread. >> >> On 02/02/2016 07:44 PM, Daniel Gryniewicz wrote: >>> On 02/02/2016 05:34 AM, Soumya Koduri wrote: >>&g

[Nfs-ganesha-devel] Patches to backport to V2.3-stable branch

Hi Malahal, Request you to backport below commits to V2.3-stable branch. commit a1d57cc5260e88e29bc4172f47566b9f313cc7f0 Author: Soumya Koduri Date: Fri Oct 30 23:11:35 2015 +0530 nfs: Use option grace_period to determine grace timeout commit

Re: [Nfs-ganesha-devel] Copy Fails with NFSv4 having Kerberos Authentication in NFS Ganesha v2.3

Hi, If you are using NFS-Ganesha sources, could you try applying below patch and verify if it fixes the issue. - https://review.gerrithub.io/#/c/274710/ Thanks, Soumya On 06/17/2016 04:51 PM, Srivastava, AshishX wrote: > Hi, > > We are using nfs ganesha v2.3. While copying with nfsv4, h

Re: [Nfs-ganesha-devel] Copy Fails with NFSv4 having Kerberos Authentication in NFS Ganesha v2.3

med then no issue is seen. > > Have to faced similar type of issue. > > Thanks > > Ashish Kr Srivastava > > -Original Message- > From: Srivastava, AshishX > Sent: Saturday, June 18, 2016 12:48 PM > To: Soumya Koduri ; > nfs-ganesha-devel@lists.sourceforge.n

Re: [Nfs-ganesha-devel] x-attr support in GlusterFS

Hi, On 06/18/2016 04:41 AM, Daniel Vega wrote: > Hello, > > I've been working on implementing x-attr support for GlusterFS. Even > though all the x-attr related functions are implemented and correctly > referenced in handle.c, I still get "Operation not supported" when > trying to set/get/list ext

Re: [Nfs-ganesha-devel] Copy Fails with NFSv4 having Kerberos Authentication in NFS Ganesha v2.3

gt; We verified the behavior on both Ubuntu and Fedora Client and still issue is > seen. Hm. Maybe its an error generated on the client-side. Have you tried enabling client-side debug logs as well? Thanks, Soumya > > Thanks > Ashish Kr Srivastava > > > -Origina

Re: [Nfs-ganesha-devel] Copy Fails with NFSv4 having Kerberos Authentication in NFS Ganesha v2.3

rror and successful scenario. > It will be helpful if you can provide any command at client side which > provide some information. > > Thanks > Ashish Kr Srivastava > > > -Original Message- > From: Soumya Koduri [mailto:skod...@redhat.com] > Sent: Monday, J

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

On 06/21/2016 06:15 AM, Malahal Naineni wrote: > I posted a patch for this here: https://review.gerrithub.io/281158 > But pynfs and cthon, they both crash ganesha due to > get_state_obj_ref(state) returning NULL. I had hit similar crash while running pynfs. Had submitted patch - https://review.

[Nfs-ganesha-devel] Invalid memory reference in "mdc_up_invalidate(..)"

Hi Dan, With the patch "7a32fb0 Daniel Gryniewicz MDCACHE - UP-call cleanups", I hit below crash in "mdc_up_invalidate(..)". https://paste.fedoraproject.org/385753/67098954/ Please check the same and let us know if we missed initializing export->sub_export anywhere in FSAL_GLUSTER? Thanks, So

Re: [Nfs-ganesha-devel] All_Squash + anonuid = 0 + anongid = 0

On 07/13/2016 02:54 AM, Frank Filz wrote: > I haven’t heard a response from anyone else, > > > > Malahal, Soumya, anyone else do you concur? > > > > Thanks > > > > Frank > > > > *From:*Ben Werthmann [mailto:b...@apcera.com] > *Sent:* Tuesday, July 12, 2016 1:51 PM > *To:* Frank Filz > *Cc:* nfs-

Re: [Nfs-ganesha-devel] My big patch set I believe will be ready to merge this week

Hi Frank, On 07/15/2016 04:29 AM, Frank Filz wrote: > I think the saga of support_ex, FSAL_MDCACHE, and copy attributes out > instead of having them in the fsal_obj_handle is finally coming to a close. > > Soumya, if you can merge on top of my patch set, and examine any patches > that change FSAL_

Re: [Nfs-ganesha-devel] Coverity issue 150368

Hi Dan, On 07/18/2016 11:55 PM, Daniel Gryniewicz wrote: > Hi, Soumya > > Coverity caught an issue (150368) with glusterfs_setttr2() that looks > legitimate. The problem is that the error cases all set status, and > then goto out. However, the first thing done after the out label is to > overwrit

Re: [Nfs-ganesha-devel] How do I prevent nfs-ganesha from keeping file handles open?

On 07/20/2016 11:09 PM, steve landiss wrote: > I am following the instructions > at > https://github.com/nfs-ganesha/nfs-ganesha/wiki/Dbusinterface#Configuring_the_System_DBus_Service > > > Ater copying the org.ganesha.nfsd.conf to /etc/dbus-1/system.d/ I get > the following error: > > "Error or

Re: [Nfs-ganesha-devel] How do I prevent nfs-ganesha from keeping file handles open?

umya > Thanks > Steve > > > On Wednesday, July 20, 2016 10:45 PM, Soumya Koduri > wrote: > > > > > On 07/20/2016 11:09 PM, steve landiss wrote: >> I am following the instructions >> at > https://github.com/nfs-ganesha/nfs-ganesha/wiki/Dbusinterface

Re: [Nfs-ganesha-devel] Assertion `item->type == CONFIG_BLOCK' failed. when

On 07/26/2016 01:26 AM, Ketan Dixit wrote: > Log snippet of the failure for reference. > > On Mon, Jul 25, 2016 at 11:46 AM, Ketan Dixit > wrote: > > Hello, > > > I compiled nfs-ganesha source code on ubuntu machine. (from the > Next branch pulled on J

Re: [Nfs-ganesha-devel] find causes sigsegv in fridgethr.c (2.4 dev)

Strange. I have been testing nfs-ganesha+gluster (master branch) on fedora. Haven't hit this issue. From both the bt looks like may be fe->ctx has gone bad. Could you please verify that in gdb? Also from the test case, since there are two clients involved, there could have been upcalls generat

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

On 07/26/2016 08:24 PM, kanishk rastogi wrote: > > hi all, > I was going though the FSAL apis and had questions regarding the lock > APi's expectation from the underlying filesystem... > > 1> Is it expected that the underlying-Filesystem will release the lock > after the lease time expires? >

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

Thanks for your inputs Frank. On 07/26/2016 09:46 PM, Frank Filz wrote: > The current FSAL lock owner implementation is a void * (though the FSAL DOES > have visibility to the actual lock owner information if it needed to use > it). Anything more would only be needed if the underlying filesystem w

Re: [Nfs-ganesha-devel] find causes sigsegv in fridgethr.c (2.4 dev)

ways after a server restart where > client does not umount and sometimes after data has been updated by > another client. I'll send a new message to the lists when I have some > repeatable examples. I see this issue too. Will look into it. Thanks, Soumya > > Thanks >

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

> > That is why we have the release_IP dBus command, it signals the Ganesha that > is giving up clients to drop their locks. Thanks a lot Frank. Right now in our HA solution, we do not send any event. So by default I guess it takes "EVENT_TAKE_IP". Will try out "EVENT_RELEASE_IP". So IIUC, the

Re: [Nfs-ganesha-devel] find causes sigsegv in fridgethr.c (2.4 dev)

sysv/linux/x86_64/pthread_cond_timedwait.S:238 > #1 0x55aeb54bb8b4 in fridgethr_freeze (thr_ctx=0x7f70b0418c00, > fr=0x7f70b0470a80) > at /usr/src/debug/nfs-ganesha-2.4-dev-26/src/support/fridgethr.c:416 > #2 fridgethr_start_routine (arg=0x7f70b0418c00) at > /usr/src/debug/nf

[Nfs-ganesha-devel] ESTALE on 'find .'

On 07/27/2016 10:45 AM, Soumya Koduri wrote: >> > >> > There could be another issue too. I have yet to create a reliable test >> > to trigger this but I often receive stale file handles in situations >> > where I would not expect to. Almost always after a s

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

Thanks again Frank for the clarification and the details. Soumya. On 07/27/2016 09:24 PM, Frank Filz wrote: >>> That is why we have the release_IP dBus command, it signals the -- _

Re: [Nfs-ganesha-devel] ESTALE on 'find .'

> fsid was broken in the attribute-copy changes. I'll submit a potential > fix for Frank to look at. Thanks Dan. James, WRT to other SEGV with upcall issue, probably it is related to a potential memory corruption in upcall processing in FSAL_GLUSTER when using glusterFS master/3.8 branch. This

Re: [Nfs-ganesha-devel] Patches to backport to V2.3-stable branch

Hi Malahal, There are quite some patches (from the earlier mails) to be backported to V2.3 branch. Please let us know if anything needed. Also I request below patch to be added as well - commit a33620087e17856610946865324e2bc750583320 Author: Soumya Koduri Date: Fri Jul 15 20:03:14 2016

Re: [Nfs-ganesha-devel] [Gluster-users] NFS-Ganesha lo traffic

On 08/09/2016 03:33 PM, Mahdi Adnan wrote: > Hi, > > Im using NFS-Ganesha to access my volume, it's working fine for now but > im seeing lots of traffic on the Loopback interface, in fact it's the > same amount of traffic on the bonding interface, can anyone please > explain to me why is this hap

Re: [Nfs-ganesha-devel] [Gluster-users] NFS-Ganesha lo traffic

On 08/09/2016 09:06 PM, Mahdi Adnan wrote: > Hi, > Thank you for your reply. > > The traffic is related to GlusterFS; > > 18:31:20.419056 IP 192.168.208.134.49058 > 192.168.208.134.49153: Flags > [.], ack 3876, win 24576, options [nop,nop,TS val 247718812 ecr > 247718772], length 0 > 18:31:20.419

Re: [Nfs-ganesha-devel] Addtional parameters that might be interesting to dynamic update

On 08/11/2016 01:23 AM, Frank Filz wrote: > Having vanquished (for the most part) dynamic export update, and the ease of > doing so, I have started to think about what other config parameters would > be useful to be able to dynamically update. How about LOG {} parameters? Changing log level witho

Re: [Nfs-ganesha-devel] Addtional parameters that might be interesting to dynamic update

On 08/11/2016 11:08 AM, Soumya Koduri wrote: > > On 08/11/2016 01:23 AM, Frank Filz wrote: >> Having vanquished (for the most part) dynamic export update, and the ease of >> doing so, I have started to think about what other config parameters would >> be useful to be ab

Re: [Nfs-ganesha-devel] MDC up call

Hi Dan, On 08/22/2016 05:40 PM, Daniel Gryniewicz wrote: > Excellent Marc, thanks. > > Soumya, could you test this with the Gluster up-calls to make sure I > didn't break them? I hit below crash when tested with the latest patchset - Program received signal SIGSEGV, Segmentation fault. [Switchin

Re: [Nfs-ganesha-devel] MDC up call

On 08/23/2016 08:19 PM, Daniel Gryniewicz wrote: > Hi, Soumya. > > I've updated the PR. Can you test again? It does work now. Thanks, Soumya > > On Tue, Aug 23, 2016 at 10:24 AM, Daniel Gryniewicz wrote: >> Thanks. I'll look at it. >> >> Daniel &g

[Nfs-ganesha-devel] md-cache (setattr2) optimization

Hi Dan/Frank, I was looking at mdcache code a bit for performance optimizations possible. I have a couple of queries. Please let me know your inputs - * In ex setattr2(), we have support for FSAL to update the attributes in the obj handle. Can we make use of them and get away with getattrs() p

Re: [Nfs-ganesha-devel] md-cache (setattr2) optimization

On 08/30/2016 02:12 AM, Frank Filz wrote: >> On 08/29/2016 01:35 PM, Soumya Koduri wrote: >>> Hi Dan/Frank, >>> >>> I was looking at mdcache code a bit for performance optimizations >>> possible. I have a couple of queries. Please let me know your in

Re: [Nfs-ganesha-devel] Blocking locks in FSALs

Hi Frank, On 09/13/2016 03:30 AM, Frank Filz wrote: >> As I have dug into things, I realize blocking locks (used by NFS v3 NLM >> clients) are broken for FSALs that don't support async blocking locks. >> >> It looks like libgfapi and libcephfs both support blocking locks (libgfapi > with >> F_SETL

  1   2   >