May 2019 - Devel - Nfs Ganesha List Archives

Change in ...nfs-ganesha[next]: FSAL_CEPH: fix length calculation in reclaim_reset

by Jeff Layton (GerritHub)

Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/453992 Change subject: FSAL_CEPH: fix length calculation in reclaim_reset ...................................................................... FSAL_CEPH: fix length calculation in reclaim_reset We need 4 characters to print a short in hex. sizeof(uint16_t) is 2. Change-Id: Ie847cc1904341aa3f2a7e03aea36cdca6d0e4a4c Reported-by: Jan Fajerski <jfajerski(a)suse.com> Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/FSAL/FSAL_CEPH/main.c 1 file changed, 3 insertions(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/92/453992/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/453992 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Ie847cc1904341aa3f2a7e03aea36cdca6d0e4a4c Gerrit-Change-Number: 453992 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com> Gerrit-MessageType: newchange

7 years

1
0
0 / 0

owner parameter in lock_op2

by fanzi2009＠hotmail.com

Hi, I'm implementing a file system FSAL which is similar to CEPH FSAL. I checked ceph_fsal_lock_op2() and other FSAL lock_op2 implementation. The owner parameter is a pointer, but it converts it to 64bit integer and sends to CEPH. Ceph will judge if it's a conflict according to this value. My question is : 1. it's possible that different clients have the same value even though the possibility is very low. 2. When this sever reboot and reclaim the lock, this value should change. Thanks, Marvin

7 years

4
4
0 / 0

Proposed Patches for 2.7.4

by Madhu P Punjabi

7 years

1
0
0 / 0

Change in ...nfs-ganesha[next]: [9P] _9p_lock doesn't process conflicts

by Malahal (GerritHub)

Malahal has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/453660 Change subject: [9P] _9p_lock doesn't process conflicts ...................................................................... [9P] _9p_lock doesn't process conflicts Since it doesn't process conflicts, it may leak holder refcount if there is a conflict. Since it is not using conflict info, just pass NULLs. Change-Id: I7aaed3412c1e2983168629cb9e67fbc629e196d1 Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com> --- M src/Protocols/9P/9p_lock.c 1 file changed, 1 insertion(+), 4 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/60/453660/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/453660 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I7aaed3412c1e2983168629cb9e67fbc629e196d1 Gerrit-Change-Number: 453660 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal <malahal(a)gmail.com> Gerrit-MessageType: newchange

7 years

1
0
0 / 0

Re: [Gluster-users] Proposing to previous ganesha HA clustersolution back to gluster code as gluster-7 feature

by Strahil

Hi Jiffin, No vendor will support your corosync/pacemaker stack if you do not have proper fencing. As Gluster is already a cluster of its own, it makes sense to control everything from there. Best Regards, Strahil NikolovOn May 3, 2019 09:08, Jiffin Tony Thottan <jthottan(a)redhat.com> wrote: > > > On 30/04/19 6:59 PM, Strahil Nikolov wrote: > > Hi, > > > > I'm posting this again as it got bounced. > > Keep in mind that corosync/pacemaker is hard for proper setup by new admins/users. > > > > I'm still trying to remediate the effects of poor configuration at work. > > Also, storhaug is nice for hyperconverged setups where the host is not only hosting bricks, but other workloads. > > Corosync/pacemaker require proper fencing to be setup and most of the stonith resources 'shoot the other node in the head'. > > I would be happy to see an easy to deploy (let say 'cluster.enable-ha-ganesha true') and gluster to be bringing up the Floating IPs and taking care of the NFS locks, so no disruption will be felt by the clients. > > > It do take care those, but need to follow certain prerequisite, but > please fencing won't configured for this setup. May we think about in > future. > > -- > > Jiffin > > > > > Still, this will be a lot of work to achieve. > > > > Best Regards, > > Strahil Nikolov > > > > On Apr 30, 2019 15:19, Jim Kinney <jim.kinney(a)gmail.com> wrote: > >> > >> +1! > >> I'm using nfs-ganesha in my next upgrade so my client systems can use NFS instead of fuse mounts. Having an integrated, designed in process to coordinate multiple nodes into an HA cluster will very welcome. > >> > >> On April 30, 2019 3:20:11 AM EDT, Jiffin Tony Thottan <jthottan(a)redhat.com> wrote: > >>> > >>> Hi all, > >>> > >>> Some of you folks may be familiar with HA solution provided for nfs-ganesha by gluster using pacemaker and corosync. > >>> > >>> That feature was removed in glusterfs 3.10 in favour for common HA project "Storhaug". Even Storhaug was not progressed > >>> > >>> much from last two years and current development is in halt state, hence planning to restore old HA ganesha solution back > >>> > >>> to gluster code repository with some improvement and targetting for next gluster release 7. > >>> > >>> I have opened up an issue [1] with details and posted initial set of patches [2] > >>> > >>> Please share your thoughts on the same > >>> > >>> > >>> Regards, > >>> > >>> Jiffin > >>> > >>> [1] https://github.com/gluster/glusterfs/issues/663 > >>> > >>> [2] https://review.gluster.org/#/q/topic:rfc-663+(status:open+OR+status:merged) > >>> > >>> > >> -- > >> Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity. > > Keep in mind that corosync/pacemaker is hard for proper setup by new admins/users. > > > > I'm still trying to remediate the effects of poor configuration at work. > > Also, storhaug is nice for hyperconverged setups where the host is not only hosting bricks, but other workloads. > > Corosync/pacemaker require proper fencing to be setup and most of the stonith resources 'shoot the other node in the head'. > > I would be happy to see an easy to deploy (let say 'cluster.enable-ha-ganesha true') and gluster to be bringing up the Floating IPs and taking care of the NFS locks, so no disruption will be felt by the clients. > > > > Still, this will be a lot of work to achieve. > > > > Best Regards, > > Strahil NikolovOn Apr 30, 2019 15:19, Jim Kinney <jim.kinney(a)gmail.com> wrote: > >> +1! > >> I'm using nfs-ganesha in my next upgrade so my client systems can use NFS instead of fuse mounts. Having an integrated, designed in process to coordinate multiple nodes into an HA cluster will very welcome. > >> > >> On April 30, 2019 3:20:11 AM EDT, Jiffin Tony Thottan <jthottan(a)redhat.com> wrote: > >>> Hi all, > >>> > >>> Some of you folks may be familiar with HA solution provided for nfs-ganesha by gluster using pacemaker and corosync. > >>> > >>> That feature was removed in glusterfs 3.10 in favour for common HA project "Storhaug". Even Storhaug was not progressed > >>> > >>> much from last two years and current development is in halt state, hence planning to restore old HA ganesha solution back > >>> > >>> to gluster code repository with some improvement and targetting for next gluster release 7. > >>> > >>> I have opened up an issue [1] with details and posted initial set of patches [2] > >>> > >>> Please share your thoughts on the same > >>> > >>> Regards, > >>> > >>> Jiffin > >>> > >>> [1] https://github.com/gluster/glusterfs/issues/663 > >>> > >>> [2] https://review.gluster.org/#/q/topic:rfc-663+(status:open+OR+status:merged) > >> > >> -- > >> Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.

7 years

2
1
0 / 0

Change in ...nfs-ganesha[next]: build: use a version script for libganesha_nfsd.so

by Kaleb KEITHLEY (GerritHub)

Kaleb KEITHLEY has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/453378 Change subject: build: use a version script for libganesha_nfsd.so ...................................................................... build: use a version script for libganesha_nfsd.so Only expose symbols needed by applications, e.g. ganesha.nfsd and the FSALs. Add link flag to the FSALs and the applications to not allow undefined symbols as an aid to developers. If a new API is added and it is used in an app or FSAL they will discover it immediately if they forget to add it to the version script. Tested (superficially) with FSAL_VFS and FSAL_GLUSTER. Note that Fedora tried, circa f28 or so, to require "-z defs" (a.k.a. --no-undefined). It will probably come back at some point, so we will be ahead of the curve here. Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com> Change-Id: I0ef14d96dc1953a340f30fb3043e1cb16a0b98e4 --- M src/CMakeLists.txt M src/FSAL/FSAL_CEPH/CMakeLists.txt M src/FSAL/FSAL_GLUSTER/CMakeLists.txt M src/FSAL/FSAL_GPFS/CMakeLists.txt M src/FSAL/FSAL_MEM/CMakeLists.txt M src/FSAL/FSAL_PROXY/CMakeLists.txt M src/FSAL/FSAL_RGW/CMakeLists.txt M src/FSAL/FSAL_VFS/panfs/CMakeLists.txt M src/FSAL/FSAL_VFS/vfs/CMakeLists.txt M src/FSAL/FSAL_VFS/xfs/CMakeLists.txt M src/FSAL/Stackable_FSALs/FSAL_NULL/CMakeLists.txt M src/MainNFSD/CMakeLists.txt A src/MainNFSD/libganesha_nfsd.ver 13 files changed, 263 insertions(+), 29 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/78/453378/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/453378 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I0ef14d96dc1953a340f30fb3043e1cb16a0b98e4 Gerrit-Change-Number: 453378 Gerrit-PatchSet: 1 Gerrit-Owner: Kaleb KEITHLEY <kaleb(a)redhat.com> Gerrit-MessageType: newchange

7 years

1
0
0 / 0

Announce Push of V2.8-dev.29

by Frank Filz

Branch next Tag:V2.8-dev.29 NOTE: There is an ntirpc pullup, please update your submodule. Release Highlights * Use array for V3_FULL_REPLY and V4_FULL_REPLY in stats. * build: (lib)ganesha_nfsd as a DSO part 2 * NFS4 - Allow locking past the FSAL's maxfilesize * Pull up ntirpc through #174 Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> Contents: 802234c Frank S. Filz V2.8-dev.29 b2f78c9 Daniel Gryniewicz Pull up ntirpc through #174 3d069bf Daniel Gryniewicz NFS4 - Allow locking past the FSAL's maxfilesize abe4d4f Kaleb S. KEITHLEY build: (lib)ganesha_nfsd as a DSO part 2 e298bf1 Gaurav Gangalwar Use array for V3_FULL_REPLY and V4_FULL_REPLY in stats. We defined type as a(stttdddddd), but using just struct.

7 years

1
0
0 / 0

Re: [Gluster-users] Proposing to previous ganesha HA clustersolution back to gluster code as gluster-7 feature

by Strahil

Keep in mind that corosync/pacemaker is hard for proper setup by new admins/users. I'm still trying to remediate the effects of poor configuration at work. Also, storhaug is nice for hyperconverged setups where the host is not only hosting bricks, but other workloads. Corosync/pacemaker require proper fencing to be setup and most of the stonith resources 'shoot the other node in the head'. I would be happy to see an easy to deploy (let say 'cluster.enable-ha-ganesha true') and gluster to be bringing up the Floating IPs and taking care of the NFS locks, so no disruption will be felt by the clients. Still, this will be a lot of work to achieve. Best Regards, Strahil NikolovOn Apr 30, 2019 15:19, Jim Kinney <jim.kinney(a)gmail.com> wrote: > > +1! > I'm using nfs-ganesha in my next upgrade so my client systems can use NFS instead of fuse mounts. Having an integrated, designed in process to coordinate multiple nodes into an HA cluster will very welcome. > > On April 30, 2019 3:20:11 AM EDT, Jiffin Tony Thottan <jthottan(a)redhat.com> wrote: >> >> Hi all, >> >> Some of you folks may be familiar with HA solution provided for nfs-ganesha by gluster using pacemaker and corosync. >> >> That feature was removed in glusterfs 3.10 in favour for common HA project "Storhaug". Even Storhaug was not progressed >> >> much from last two years and current development is in halt state, hence planning to restore old HA ganesha solution back >> >> to gluster code repository with some improvement and targetting for next gluster release 7. >> >> I have opened up an issue [1] with details and posted initial set of patches [2] >> >> Please share your thoughts on the same >> >> Regards, >> >> Jiffin >> >> [1] https://github.com/gluster/glusterfs/issues/663 >> >> [2] https://review.gluster.org/#/q/topic:rfc-663+(status:open+OR+status:merged) > > > -- > Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.

7 years

3
2
0 / 0

Proposing to previous ganesha HA cluster solution back to gluster code as gluster-7 feature

by Jiffin Tony Thottan

Hi all, Some of you folks may be familiar with HA solution provided for nfs-ganesha by gluster using pacemaker and corosync. That feature was removed in glusterfs 3.10 in favour for common HA project "Storhaug". Even Storhaug was not progressed much from last two years and current development is in halt state, hence planning to restore old HA ganesha solution back to gluster code repository with some improvement and targetting for next gluster release 7. I have opened up an issue [1] with details and posted initial set of patches [2] Please share your thoughts on the same Regards, Jiffin [1]https://github.com/gluster/glusterfs/issues/663 <https://github.com/gluster/glusterfs/issues/663> [2] https://review.gluster.org/#/q/topic:rfc-663+(status:open+OR+status:merged)

7 years

3
3
0 / 0

Change in ...nfs-ganesha[next]: build: (lib)ganesha_nfsd as a DSO

by Name of user not set (GerritHub)

kaleb(a)redhat.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/452909 Change subject: build: (lib)ganesha_nfsd as a DSO ...................................................................... build: (lib)ganesha_nfsd as a DSO Build ganesha as a DSO, i.e. libganesha_nfsd.so. While working on building with -flto (link time optimization) I discovered that libfsalvfs.so was missing vfs_is_dummy_handle(), throwing an unresolved symbol error at run-time. It's unclear why this doesn't happen with non-flto builds. Perhaps building with -flto requires stricter run-time link semantics. The ganesha.nfsd daemon consists of just nfs_main:main() and is linked with the DSO. Then all the FSALs (except FSAL_PSEUDO and FSAL_MDCACHE*) are linked with libganesha_nfsd to resolve functions in ganesha.nfsd itself. This will be required if, e.g., Fedora, decides to require default linking with '-z defs'. They tried to do it for F29 but retreated when they found that too many applications broke. In the end this may all be just an exercise in "truth and beauty." There are other use cases envisioned where ganesha is embedded as a component as part of other software components. *FSAL_PSEUDO and FSAL_MDCACHE are special; they are included in the DSO so should not need to be (and can't be) linked with the DSO. Cmake OBJECT libraries are not actual libraries like .a static or .so shared libs; they just compile the sources to .o files which are collectively referenced with cmake's $<TARGET_OBJECTS:...>. As such it is necessary to use set_target_properties(... COMPILE_FLAGS "-fPIC") everywhere. A few other things that could be done in the future are 1) link libganesha_nfsd.so with a .sym file to explicitly control which symbols are exposed or visible to the outside world. 2) build with -flto (Link Time Optimization) Annecdotes claim a 5-10% speed improvement is typical, and some applications have seen as much as 45-50% boost. Of course we have to do the experiment to see what we can really achieve. 3) don't link ganesha.nfsd with -bdynamic as it's no longer needed Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com> Change-Id: I7941cbd4ec68f15a3f5514046b2ee40130fb6414 --- M src/FSAL/FSAL_VFS/os/CMakeLists.txt M src/FSAL/FSAL_VFS/vfs/CMakeLists.txt 2 files changed, 2 insertions(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/09/452909/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/452909 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I7941cbd4ec68f15a3f5514046b2ee40130fb6414 Gerrit-Change-Number: 452909 Gerrit-PatchSet: 1 Gerrit-Owner: kaleb(a)redhat.com Gerrit-MessageType: newchange

7 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

Devel May 2019