Re: [Nfs-ganesha-devel] Request to merge patches to V2.2-stable branch
I didn't see GLUSTERFSAL_UP_Thread() returning anything other than NULL/0. I think passing NULL to pthread_join is even cleaner! Regards, Malahal. Malahal Naineni [mala...@us.ibm.com] wrote: Soumya Koduri [skod...@redhat.com] wrote: 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 I just looked at the patch from your other mail. I have few questions on this patch. 1. I am not sure why you declared retval as int *. Does the up_thread exists with an int *? Most threads just exit with an integer, so declaring just int retval or a later casting would have been suffice. 2. Technically, passed in OUT argument is updated by pthead_join() only on success, so it should be valid only if pthead_join() returned success (usually this should NOT fail though). All in all, the code should be something like this: int retval; err = pthread_join(up_thread, (void**)retval); if (err) LogCrit(XX, pthread_join faild: %d, err); else LogDebug(XX, upthread exited with: %d, retval); Checking for '*retval' is only useful if your up_thread exited with something like pthread_exit(some_var), but I don't think it does that. Regards, Malahal. PS: I am just looking at the manpage, no direct experince! Did you ever see the system printing a sane Up_thread join returned value %d message? -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] Problems in /usr/libexec/ganesha/dbus-send.sh and ganesha dbus interface when disabling exports from gluster
Hi Soumya,
Il giorno 17/giu/2015, alle ore 19:41, Soumya Koduri skod...@redhat.com ha
scritto:
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 volume
ganesha.enable off, I always get the following error:
Error: Dynamic export addition/deletion failed. Please see log file for
details
This message is produced by the failure of
/usr/libexec/ganesha/dbus-send.sh, and in fact if I manually perform the
command to remove the share I see:
you got it wrong. '/usr/libexec/ganesha/dbus-send.sh' is used by Gluster-CLI
to unexport the volume gluster volume set volname ganesha.enable off
which rightly deletes the export file too while un-exporting the volume.
Indeed, but the code is the following, only showing the two important functions:
function check_cmd_status()
{
if [ $1 != 0 ]
then
rm -rf $GANESHA_DIR/exports/export.$VOL.conf
exit 1
fi
}
function dynamic_export_remove()
{
removed_id=`cat $GANESHA_DIR/exports/export.$VOL.conf |\
grep Export_Id | cut -d -f8`
check_cmd_status `echo $?`
dbus-send --print-reply --system \
--dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr \
org.ganesha.nfsd.exportmgr.RemoveExport uint16:$removed_id
check_cmd_status `echo $?`
sed -i /$VOL.conf/d $CONF
rm -rf $GANESHA_DIR/exports/export.$VOL.conf
}
So, if the dbus-send fails the function check_cmd_status() just deletes
$GANESHA_DIR/exports/export.$VOL.conf and then quits the whole script, so the
last two lines (the sed and the rm) are never executed in
dynamic_export_remove()
# dbus-send --print-reply --system --dest=org.ganesha.nfsd
/org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2
Error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply
(timeout by message bus)
So, there is a timeout and it fails completely.
Check if nfs-ganesha is still running. There was a bug in unexporting the
volume. Its been fixed recently in V2.3-dev, yet to be back-ported to
V2.2-stable branch.
https://review.gerrithub.io/#/c/236129/
Ah, I see! Yes, ganesha was still alive, otherwise the message would have been
different (something like ganesha is unknown by messagebus), and I have also
checked with service nfs-ganesha status. However, probably due to the bug
you’re mentioning, without issuing e.g. a DisplayExport I’m always getting
timeouts.
Thanks,
Alessandro
Thanks,
Soumya
In this case I think there is a bug in /usr/libexec/ganesha/dbus-send.sh,
since it blindly deletes the share config if the RemoveExport fails
(function check_cmd_status()), but leaves the %include inside ganesha.conf
as in the check_cmd_status() there is a runaway condition and the other
removal statements are then not executed. I believe the logic should be
fixed here, otherwise even a restart of the service will fail due to the bad
configuration.
What’s more worrying is the problem with the dbus. Issuing a DisplayExport
before the RemoveExport apparently fixes the problem, so something like this
always works:
# dbus-send --print-reply --system --dest=org.ganesha.nfsd
/org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.DisplayExport uint16:2
# dbus-send --print-reply --system --dest=org.ganesha.nfsd
/org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2
So, it’s like the DisplayExport is forcing someway a refresh that is needed
by the RemoveExport. Any idea why?
I’m using the latest version of ganesha 2.2.0, i.e. 2.2.0-3.
Thanks,
Alessandro
PS: sorry for reporting so many things in a few days :-)
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
smime.p7s
Description: S/MIME cryptographic signature
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[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, Soumya -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] Request to merge patches to V2.2-stable branch
Soumya Koduri [skod...@redhat.com] wrote: 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 I just looked at the patch from your other mail. I have few questions on this patch. 1. I am not sure why you declared retval as int *. Does the up_thread exists with an int *? Most threads just exit with an integer, so declaring just int retval or a later casting would have been suffice. 2. Technically, passed in OUT argument is updated by pthead_join() only on success, so it should be valid only if pthead_join() returned success (usually this should NOT fail though). All in all, the code should be something like this: int retval; err = pthread_join(up_thread, (void**)retval); if (err) LogCrit(XX, pthread_join faild: %d, err); else LogDebug(XX, upthread exited with: %d, retval); Checking for '*retval' is only useful if your up_thread exited with something like pthread_exit(some_var), but I don't think it does that. Regards, Malahal. PS: I am just looking at the manpage, no direct experince! Did you ever see the system printing a sane Up_thread join returned value %d message? -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] Problems in /usr/libexec/ganesha/dbus-send.sh and ganesha dbus interface when disabling exports from gluster
Alessandro De Salvo [alessandro.desa...@roma1.infn.it] wrote: What’s more worrying is the problem with the dbus. Issuing a DisplayExport before the RemoveExport apparently fixes the problem, so something like this always works: # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.DisplayExport uint16:2 # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2 So, it’s like the DisplayExport is forcing someway a refresh that is needed by the RemoveExport. Any idea why? I’m using the latest version of ganesha 2.2.0, i.e. 2.2.0-3. I used the same exact command above (the second one that removes an export) after restarting ganesha, and it just worked fine. I use GPFS FSAL (neither gluster nor VFS). Not sure why you need to use DisplayExport before using RemoveExport. Try to trace 'DBUS' component at FULL_DEBUG (or maybe everything at FULL_DEBUG) and post the log. The error you reported means we are NOT responding to the dbus message which is very odd! Reagrds, Malahal. -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] Problems in /usr/libexec/ganesha/dbus-send.sh and ganesha dbus interface when disabling exports from gluster
Hi Malahal, Il giorno 17/giu/2015, alle ore 19:51, Malahal Naineni mala...@us.ibm.com ha scritto: Alessandro De Salvo [alessandro.desa...@roma1.infn.it] wrote: What’s more worrying is the problem with the dbus. Issuing a DisplayExport before the RemoveExport apparently fixes the problem, so something like this always works: # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.DisplayExport uint16:2 # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2 So, it’s like the DisplayExport is forcing someway a refresh that is needed by the RemoveExport. Any idea why? I’m using the latest version of ganesha 2.2.0, i.e. 2.2.0-3. I used the same exact command above (the second one that removes an export) after restarting ganesha, and it just worked fine. I use GPFS FSAL (neither gluster nor VFS). Not sure why you need to use DisplayExport before using RemoveExport. Try to trace 'DBUS' component at FULL_DEBUG (or maybe everything at FULL_DEBUG) and post the log. The error you reported means we are NOT responding to the dbus message which is very odd! Indeed! This is why I was worried :-) I’m attaching the ganesha.log with NIV_FULL_DEBUG, you can see the restart at the end, due to my attempt of RemoveExport, which always gave me the same error as before. Thanks, Alessandro ganesha-20150617.log.gz Description: GNU Zip compressed data Reagrds, Malahal. smime.p7s Description: S/MIME cryptographic signature -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Add FSAL helpers for rename access checking
From Daniel Gryniewicz d...@cohortfs.com: Daniel Gryniewicz has uploaded a new change for review. https://review.gerrithub.io/236840 Change subject: Add FSAL helpers for rename access checking .. Add FSAL helpers for rename access checking Rename is basically a remove and an add, from a permissions checking point of view. Add a helper to check this, and call it when FSAL_VFS debugging is on. Change-Id: I0f453fede3615edb70983a565d7be9c205528107 Signed-off-by: Daniel Gryniewicz d...@cohortfs.com --- M src/FSAL/FSAL_VFS/handle.c M src/FSAL/commonlib.c M src/include/FSAL/fsal_commonlib.h 3 files changed, 38 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/40/236840/1 -- To view, visit https://review.gerrithub.io/236840 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I0f453fede3615edb70983a565d7be9c205528107 Gerrit-PatchSet: 1 Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Owner: Daniel Gryniewicz d...@cohortfs.com -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Problems in /usr/libexec/ganesha/dbus-send.sh and ganesha dbus interface when disabling exports from gluster
Hi, when disabling exports from gluster 3.7.1, by using gluster vol set volume ganesha.enable off, I always get the following error: Error: Dynamic export addition/deletion failed. Please see log file for details This message is produced by the failure of /usr/libexec/ganesha/dbus-send.sh, and in fact if I manually perform the command to remove the share I see: # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2 Error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) So, there is a timeout and it fails completely. In this case I think there is a bug in /usr/libexec/ganesha/dbus-send.sh, since it blindly deletes the share config if the RemoveExport fails (function check_cmd_status()), but leaves the %include inside ganesha.conf as in the check_cmd_status() there is a runaway condition and the other removal statements are then not executed. I believe the logic should be fixed here, otherwise even a restart of the service will fail due to the bad configuration. What’s more worrying is the problem with the dbus. Issuing a DisplayExport before the RemoveExport apparently fixes the problem, so something like this always works: # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.DisplayExport uint16:2 # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2 So, it’s like the DisplayExport is forcing someway a refresh that is needed by the RemoveExport. Any idea why? I’m using the latest version of ganesha 2.2.0, i.e. 2.2.0-3. Thanks, Alessandro PS: sorry for reporting so many things in a few days :-) smime.p7s Description: S/MIME cryptographic signature -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] Problems in /usr/libexec/ganesha/dbus-send.sh and ganesha dbus interface when disabling exports from gluster
I have no knowledge of dbus-send.sh, is it GLUSTER fsal specific? I don't see it in ganesha source code at all. I use ganesha_mgr command to show/delete/remove exports. Can you try it and see if that works? ganesha_mgr remove_export 2 should be the correct call in your case. Regards, Malahal. Alessandro De Salvo [alessandro.desa...@roma1.infn.it] wrote: Hi, when disabling exports from gluster 3.7.1, by using gluster vol set volume ganesha.enable off, I always get the following error: Error: Dynamic export addition/deletion failed. Please see log file for details This message is produced by the failure of /usr/libexec/ganesha/dbus-send.sh, and in fact if I manually perform the command to remove the share I see: # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2 Error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) So, there is a timeout and it fails completely. In this case I think there is a bug in /usr/libexec/ganesha/dbus-send.sh, since it blindly deletes the share config if the RemoveExport fails (function check_cmd_status()), but leaves the %include inside ganesha.conf as in the check_cmd_status() there is a runaway condition and the other removal statements are then not executed. I believe the logic should be fixed here, otherwise even a restart of the service will fail due to the bad configuration. What’s more worrying is the problem with the dbus. Issuing a DisplayExport before the RemoveExport apparently fixes the problem, so something like this always works: # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.DisplayExport uint16:2 # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2 So, it’s like the DisplayExport is forcing someway a refresh that is needed by the RemoveExport. Any idea why? I’m using the latest version of ganesha 2.2.0, i.e. 2.2.0-3. Thanks, Alessandro PS: sorry for reporting so many things in a few days :-) -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
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 volume ganesha.enable off, I always get the following error: Error: Dynamic export addition/deletion failed. Please see log file for details This message is produced by the failure of /usr/libexec/ganesha/dbus-send.sh, and in fact if I manually perform the command to remove the share I see: you got it wrong. '/usr/libexec/ganesha/dbus-send.sh' is used by Gluster-CLI to unexport the volume gluster volume set volname ganesha.enable off which rightly deletes the export file too while un-exporting the volume. # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2 Error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) So, there is a timeout and it fails completely. Check if nfs-ganesha is still running. There was a bug in unexporting the volume. Its been fixed recently in V2.3-dev, yet to be back-ported to V2.2-stable branch. https://review.gerrithub.io/#/c/236129/ Thanks, Soumya In this case I think there is a bug in /usr/libexec/ganesha/dbus-send.sh, since it blindly deletes the share config if the RemoveExport fails (function check_cmd_status()), but leaves the %include inside ganesha.conf as in the check_cmd_status() there is a runaway condition and the other removal statements are then not executed. I believe the logic should be fixed here, otherwise even a restart of the service will fail due to the bad configuration. Yes. I see that the sed -i /$VOL.conf/d $CONF is placed after the check_cmd_status. I shall send a fix upstream in a related bug. But dynamic export removal will fail in three cases, 1. nfs-ganesha is not running. 2. The export file that is particular to that volume is somehow deleted before you perform the removal. It does depend on that file to get the export ID. 3. The bug that Soumya pointed out. If it is failing consistently, there could be something that you are missing. If you can send the exact sequence of sequence of steps that you have executed, I can help you with it. Ideally after exporting a particular volume, you'll see an entry in the /etc/ganesha/ganesha.conf file and the export file in /etc/ganesha/exports dir. If you have this in place and nfs-ganesha running, then dynamic export removal should work just fine. Meghana What’s more worrying is the problem with the dbus. Issuing a DisplayExport before the RemoveExport apparently fixes the problem, so something like this always works: # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.DisplayExport uint16:2 # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:2 So, it’s like the DisplayExport is forcing someway a refresh that is needed by the RemoveExport. Any idea why? I’m using the latest version of ganesha 2.2.0, i.e. 2.2.0-3. Thanks, Alessandro PS: sorry for reporting so many things in a few days :-) -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] [Gluster-users] Questions on ganesha HA and shared storage size
Hi,
I would actually prefer that we solve the issue with using the unbundled
libntirpc. That seems like the better long term solution, and one we
have to tackle anyway as we have a hard end date for using the bundled
libntirpc in Fedora and EPEL.
In the mean time I've reverted the EPEL 7 build (and perhaps the Fedora
Rawhide build too) to use the bundled lib. Packages will land in Fedora
and EPEL after a nominal testing period. Or you can get them sooner by
enabling the Updates-Testing repo in
/etc/yum.repos.d/{fedora-updates-testing,epel-testing}.repo
Regards,
--
Kaleb
On 06/16/2015 07:57 PM, Malahal Naineni wrote:
Thank you Niels for your time to chase the issue. It is important to
have working files as people try, and move on if things don't work.
Not everyone is as persistent as Alessandro!
Regards, Malahal.
Niels de Vos [nde...@redhat.com] wrote:
On Mon, Jun 15, 2015 at 06:50:21PM -0500, Malahal Naineni wrote:
Kaleb Keithley [kkeit...@redhat.com] wrote:
But note that nfs-ganesha in EPEL[67] is built with a) glusterfs-api-3.6.x
from Red Hat's downstream glusterfs, and b) the bundled static version
of ntirpc, not the shared lib in the stand-along package above. If you're
trying to use these packages with glusterfs-3.7.x then I guess I'm not too
surprised if something isn't working. Look for nfs-ganesha packages built
against glusterfs-3.7.x in the CentOS Storage SIG or watch for the same on
download.gluster.org. They're not there yet, but they will be eventually.
If I understood the issue, he wasn't even using gluster FSAL (he wasn't
using any exports at all). His issue is probably unrelated to any
gluster API changes.
It seems that un-bunding the libntirpc causes this problem. Bisecting
the NFS-Ganesha package builds for the epel7 branch show this. Also,
re-bundling the libntirpc package makes nfs-ganesha-2.2.0 work again. I
do not know yet where the actual problem is, maybe the libntirpc package
in Fedora/EPEL does not work correctly, or there are some linker changes
needed for NFS-Ganesha to build against the non-bundled libntirpc.
I've only tested on CentOS-7 for now. Maybe the Fedora 22 libntirpc and
nfs-ganesha packages have the same problem?
In case someone cares, this is my patch against the current epel7
nfs-ganesha.spec: http://paste.fedoraproject.org/232837/44926521/
Cheers,
Niels
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Kaleb
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] [Gluster-users] Questions on ganesha HA and shared storage size
On Wed, Jun 17, 2015 at 08:27:57AM -0400, Kaleb S. KEITHLEY wrote:
Hi,
I would actually prefer that we solve the issue with using the unbundled
libntirpc. That seems like the better long term solution, and one we
have to tackle anyway as we have a hard end date for using the bundled
libntirpc in Fedora and EPEL.
Of course, that is the plan. I still need to test on Fedora where
libntirpc was unbundled. Unfortunately there are very little other users
of libntirpc, so testing with a non-ganesha application is not as
simple as I hoped.
I'll continue to investigate this in small steps. When I have more ideas
on what the problem could be, I'll inform everyone :)
In the mean time I've reverted the EPEL 7 build (and perhaps the Fedora
Rawhide build too) to use the bundled lib. Packages will land in Fedora
and EPEL after a nominal testing period. Or you can get them sooner by
enabling the Updates-Testing repo in
/etc/yum.repos.d/{fedora-updates-testing,epel-testing}.repo
Thanks, that surely works for the immediate problem.
Niels
Regards,
--
Kaleb
On 06/16/2015 07:57 PM, Malahal Naineni wrote:
Thank you Niels for your time to chase the issue. It is important to
have working files as people try, and move on if things don't work.
Not everyone is as persistent as Alessandro!
Regards, Malahal.
Niels de Vos [nde...@redhat.com] wrote:
On Mon, Jun 15, 2015 at 06:50:21PM -0500, Malahal Naineni wrote:
Kaleb Keithley [kkeit...@redhat.com] wrote:
But note that nfs-ganesha in EPEL[67] is built with a)
glusterfs-api-3.6.x from Red Hat's downstream glusterfs, and b) the
bundled static version of ntirpc, not the shared lib in the
stand-along package above. If you're trying to use these packages with
glusterfs-3.7.x then I guess I'm not too surprised if something isn't
working. Look for nfs-ganesha packages built against glusterfs-3.7.x in
the CentOS Storage SIG or watch for the same on download.gluster.org.
They're not there yet, but they will be eventually.
If I understood the issue, he wasn't even using gluster FSAL (he wasn't
using any exports at all). His issue is probably unrelated to any
gluster API changes.
It seems that un-bunding the libntirpc causes this problem. Bisecting
the NFS-Ganesha package builds for the epel7 branch show this. Also,
re-bundling the libntirpc package makes nfs-ganesha-2.2.0 work again. I
do not know yet where the actual problem is, maybe the libntirpc package
in Fedora/EPEL does not work correctly, or there are some linker changes
needed for NFS-Ganesha to build against the non-bundled libntirpc.
I've only tested on CentOS-7 for now. Maybe the Fedora 22 libntirpc and
nfs-ganesha packages have the same problem?
In case someone cares, this is my patch against the current epel7
nfs-ganesha.spec: http://paste.fedoraproject.org/232837/44926521/
Cheers,
Niels
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Kaleb
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: 9P/RDMA: init opctx in cleanup_fids
From Dominique Martinet dominique.marti...@cea.fr: Dominique Martinet has uploaded a new change for review. https://review.gerrithub.io/236752 Change subject: 9P/RDMA: init opctx in cleanup_fids .. 9P/RDMA: init opctx in cleanup_fids Change-Id: I490749dbee23fd69dee85d0928dd617f0f285a95 Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- M src/Protocols/9P/9p_proto_tools.c 1 file changed, 2 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/52/236752/1 -- To view, visit https://review.gerrithub.io/236752 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I490749dbee23fd69dee85d0928dd617f0f285a95 Gerrit-PatchSet: 1 Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Owner: Dominique Martinet dominique.marti...@cea.fr -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Error handling: handle FSAL's ENODATA (xattr)
From Dominique Martinet dominique.marti...@cea.fr: Dominique Martinet has uploaded a new change for review. https://review.gerrithub.io/236763 Change subject: Error handling: handle FSAL's ENODATA (xattr) .. Error handling: handle FSAL's ENODATA (xattr) This change is mainly for 9P since NFS doesn't handle xattrs. The previous commit makes that we do not actually need all the conversions, but we still get a lot of lines like this: posix2fsal_error :FSAL :CRIT :Mapping 61(default) to ERR_FSAL_SERVERFAULT NFS error conversions still return serverfault on posix error ENODATA as it used to. Change-Id: I440916e76e25b3c9b8af726dc92e4483315e7f35 Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- M src/FSAL/fsal_convert.c M src/Protocols/9P/9p_proto_tools.c M src/SAL/state_misc.c M src/cache_inode/cache_inode_misc.c M src/include/fsal_types.h M src/include/gsh_status.h M src/support/nfs_convert.c 7 files changed, 17 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/63/236763/1 -- To view, visit https://review.gerrithub.io/236763 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-MessageType: newchange Gerrit-Change-Id: I440916e76e25b3c9b8af726dc92e4483315e7f35 Gerrit-PatchSet: 1 Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Owner: Dominique Martinet dominique.marti...@cea.fr -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Another fsal_grace question
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 requests down to FSAL.
Then, fsal_grace was made to be configured in FSAL{} block. The logic
also changed a bit with the commit! Now, we do call nfs_in_grace() and
then check for fsal_grace boolean.
Here is the simplified logic for some requests:
if (ganesha is in grace) {
only reclaims are allowed UNLESS fsal_grace is set.
If fsal_grace is set, we allow NON-reclaim requests.
} else {
A reclaim request is returned with NO_GRACE error (it doesn't
matter if fsal_grace is set or not).
non-reclaim requests allowed as expected.
}
Based on the above code, fsal_grace MAY allow us to satisfy some
non-reclaim requests under grace period. Is this its purpose?
Regards, Malahal.
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: VFS/xattrs: add symlink handling to getextattr_id_by_name
From Dominique Martinet dominique.marti...@cea.fr: Dominique Martinet has uploaded a new change for review. https://review.gerrithub.io/236761 Change subject: VFS/xattrs: add symlink handling to getextattr_id_by_name .. VFS/xattrs: add symlink handling to getextattr_id_by_name 9P apparently calls this function on symlinks with posixacl Change-Id: Ieb521b7d03f41856577a299b8d17fdd3557c04dc Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- M src/FSAL/FSAL_VFS/xattrs.c 1 file changed, 12 insertions(+), 3 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/61/236761/1 -- To view, visit https://review.gerrithub.io/236761 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ieb521b7d03f41856577a299b8d17fdd3557c04dc Gerrit-PatchSet: 1 Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Owner: Dominique Martinet dominique.marti...@cea.fr -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: 9P: statfs: replace NFS magic type by 9P's
From Dominique Martinet dominique.marti...@cea.fr: Dominique Martinet has uploaded a new change for review. https://review.gerrithub.io/236753 Change subject: 9P: statfs: replace NFS magic type by 9P's .. 9P: statfs: replace NFS magic type by 9P's This matters for umount, that tries to call umount.nfs on recent systems Change-Id: Iabec860596b1fa3e8aea2b98ca91cf6b4a8426fd Signed-off-by: Dominique Martinet dominique.marti...@cea.fr --- M src/Protocols/9P/9p_statfs.c 1 file changed, 1 insertion(+), 2 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/53/236753/1 -- To view, visit https://review.gerrithub.io/236753 To unsubscribe, visit https://review.gerrithub.io/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Iabec860596b1fa3e8aea2b98ca91cf6b4a8426fd Gerrit-PatchSet: 1 Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Owner: Dominique Martinet dominique.marti...@cea.fr -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
Re: [Nfs-ganesha-devel] Ganesha crash on a rm
Hi Krishna, The code doesn't seem to match exactly with V2.1.0 but it does look like nfs3_remove() entered label out_fail. Wondering what the cache_status was at the time of the crash. There were some fixes in V2.2-stable related refcounting, but I am not sure if V2.2-stable fixes your issues. What FSAL are you using? Also, if you can reproduce this under valgrind, that should give us more information to see if we are using the freed entry itself here. As I said, I don't see any commit in particular that fixes this issue but V2.2- stable is the current release (and it is our long term release!) I would like to see this recreated on V2.2.0 before doing too much digging. Due to the significant stability issues addressed in V2.2.0, it's quite possible that issues have been fixed without understanding exactly the impact of various fixes. Frank Krishna Harathi [khara...@exablox.com] wrote: Using Ganesha version 2.1.0, NFSv3 exports and clients. We are seeing the following crash where Ganesha is trying to access parent inode to SetPostOpAttr() and ion the crash, we see that the parent obj_handle is NULL. Is this a known issue, and are there any recent fices in this area? Any help is appreciated. Thread 1 (LWP 6688): #0 0x0050ad94 in cache_inode_is_attrs_valid (entry=0x6b424500) at /git/packaging/nfs-ganesha/nfs-ganesha/src/include/cache_inode.h:939 #1 0x0050e5d8 in cache_inode_lock_trust_attrs (entry=0x6b424500, need_wr_lock=false) at /git/packaging/nfs-ganesha/nfs- ganesha/src/cache_inode/cache_inode_mis c.c:887 #2 0x004a1e04 in cache_entry_to_nfs3_Fattr (entry=0x6b424500, Fattr=0x698092f0) at /git/packaging/nfs-ganesha/nfs- ganesha/src/Protocols/NFS/nfs_proto_too ls.c:3567 #3 0x0049a940 in nfs_SetPostOpAttr (entry=0x6b424500, attr=0x698092e8) at /git/packaging/nfs-ganesha/nfs- ganesha/src/Protocols/NFS/nfs_proto_too ls.c:79 #4 0x0049abc8 in nfs_SetWccData (before_attr=0x70ffdc00, entry=0x6b424500, wcc_data=0x698092c8) at /git/packaging/nfs-ganesha/nfs- ganesha/src/Protocols/NFS/nfs_proto_too ls.c:132 #5 0x00466bbc in nfs3_remove (arg=0x5fc90358, worker=0x6f008140, req=0x5fc902e8, res=0x698092c0) at /git/packaging/nfs-ganesha/nfs- ganesha/src/Protocols/NFS/nfs3_remove.c :161 #6 0x0045b340 in nfs_rpc_execute (req=0x5fc72d30, worker_data=0x6f008140) at /git/packaging/nfs-ganesha/nfs- ganesha/src/MainNFSD/nfs_worker_thread. c:1257 #7 0x0045bfa8 in worker_run (ctx=0x76562f00) at /git/packaging/nfs-ganesha/nfs- ganesha/src/MainNFSD/nfs_worker_thread. c:1506 #8 0x00542684 in fridgethr_start_routine (arg=0x76562f00) at /git/packaging/nfs-ganesha/nfs-ganesha/src/support/fridgethr.c:562 #9 0x76f47368 in start_thread () from /lib/mips-linux-gnu/libpthread.so.0 #10 0x76e9af18 in fcvt_r () from /lib/mips-linux-gnu/libc.so.6 #11 0x in ?? () (gdb) f 0 #0 0x0050ad94 in cache_inode_is_attrs_valid (entry=0x6b424500) at /git/packaging/nfs-ganesha/nfs- ganesha/src/include/cache_inode.h:939 939in /git/packaging/nfs-ganesha/nfs- ganesha/src/include/cache_inode.h (gdb) p entry-obj_handle $1 = (struct fsal_obj_handle *) 0x0 Regards. Krishna Harathi -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel -- ___ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
