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
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
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
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
Hi,
any news on this? Did you have the chance to look into that?
I'd also be curious to know if anyone tried nfs ganesha on CentOS 7.1
and if it was really working, as I also tried on a standalone, clean
machine, and I see the very same behavior, even without gluster.
Thanks,
Alessandro
We do run ganesha on RHEL7.0 (same as CentOS7.0), and I don't think 7.1
would be much different. We do run GPFS FSAL only (no VFS_FSAL).
Regards, Malahal.
Alessandro De Salvo [alessandro.desa...@roma1.infn.it] wrote:
Hi,
any news on this? Did you have the chance to look into that?
I'd also be
I am not familiar with tirpc code, but how are you building ganesha
rpms? Did you do git submodule update to get the latest tirpc code
when you built those rpms? Can somebody familiar with tirpc chime in?
The one I use is below:
# git submodule status
b1a82463c4029315fac085a9d0d6bef766847ed7
OK, thanks, so, any hint on what I could check now?
I have tried even without any VFS, so with just the nfs-ganesha rpm installed
and with an empty ganesha.conf, but still the same problem. The same
configuration with ganesha 2.1.0 was working, on the same server.
Any idea? I have sent you the
Hi Malahal,
I have downloaded and used the tarball created by git for the stable 2.2.0
branch, so it should have been consistent. Also, I have used the spec file from
Epel to build the rpms. I’m going to try your procedure as well now, to see if
anything changes.
Thanks,
Alessandro
Alessandro De Salvo [alessandro.desa...@roma1.infn.it] wrote:
OK, I think we are now closer to the end of the story.
Recompiling with your instructions, and slightly changing the release name to
match the convention in epel, the new RPMS produce something working!
So it means essentially
Alessandro De Salvo [alessandro.desa...@roma1.infn.it] wrote:
Hi Malahal,
--- nfs-ganesha.orig/src/nfs-ganesha.spec-in.cmake 2015-06-16
00:11:31.477442950 +0200
+++ nfs-ganesha/src/nfs-ganesha.spec-in.cmake 2015-06-15 22:11:57.068726917
+0200
@@ -72,13 +72,13 @@
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
Hi Malahal,
Il giorno 15/giu/2015, alle ore 23:30, Malahal Naineni mala...@us.ibm.com
ha scritto:
Alessandro De Salvo [alessandro.desa...@roma1.infn.it] wrote:
OK, I think we are now closer to the end of the story.
Recompiling with your instructions, and slightly changing the release name
OK, I think we are now closer to the end of the story.
Recompiling with your instructions, and slightly changing the release name to
match the convention in epel, the new RPMS produce something working!
So it means essentially that:
1) the RPMS in epel are broken, they should really be fixed;
2)
- Original Message -
From: Malahal Naineni mala...@us.ibm.com
...
PS: there were some efforts to make ntirpc as an rpm by itself. Not sure where
that is.
google[1] will tell you that libntirpc is in fact a stand-alone package in
Fedora and EPEL, and as you can see at [2] it's
Hi,
exactly, I confirm this, I was not even reaching the point of using the gluster
FSAL, so it should be unrelated, I guess.
Cheers,
Alessandro
Il giorno 16/giu/2015, alle ore 01:50, Malahal Naineni mala...@us.ibm.com
ha scritto:
Kaleb Keithley [kkeit...@redhat.com] wrote:
But
Hi Malahal,
Il giorno 12/giu/2015, alle ore 01:23, Malahal Naineni mala...@us.ibm.com
ha scritto:
The logs indicate that ganesha was started successfully without any
exports. gstack output seemed normal as well -- threads were waiting to
serve requests.
Yes, no exports as it was the
Hi,
looking at the code and having recompiled adding some more debug, I
might be wrong, but it seems that in nfs_rpc_dispatcher_thread.c,
fuction nfs_rpc_dequeue_req, the threads enter the while (!(wqe-flags
Wqe_LFlag_SyncDone)) and never exit from there.
I do not know if it's normal or not as I
The logs indicate that ganesha was started successfully without any
exports. gstack output seemed normal as well -- threads were waiting to
serve requests.
Assuming that you are running showmount -e on the same system, there
shouldn't be any firewall coming into the picture. If you are running
Hi,
this was an extract from the old logs, before Soumya's suggestion of
changing the rquota port in the conf file. The new logs are attached
(ganesha-20150611.log.gz) as well as the gstack of the ganesha process
while I was executing the hanging showmount
(ganesha-20150611.gstack.gz).
Thanks,
Soumya Koduri [skod...@redhat.com] wrote:
CCin ganesha-devel to get more inputs.
In case of ipv6 enabled, only v6 interfaces are used by NFS-Ganesha.
I am not a network expert but I have seen IPv4 traffic over IPv6 interface
while fixing few things before. This may be normal.
IPv6 can
Soumya Koduri [skod...@redhat.com] wrote:
CCin ganesha-devel to get more inputs.
In case of ipv6 enabled, only v6 interfaces are used by NFS-Ganesha.
I am not a network expert but I have seen IPv4 traffic over IPv6
interface while fixing few things before. This may be normal.
commit - git
22 matches
Mail list logo
