Worst case, you could add "%_with_ceph 1" on a line by itself in your
~/.rpmmacros file, then it should work!
Regards, Malahal.
On Thu, Aug 25, 2016 at 7:14 PM, Malahal Naineni wrote:
> When you run your cmake, it creates nfs-ganesha.spec file. If you have
>
> %bcond_with ceph
> %global use_fsal
When you run your cmake, it creates nfs-ganesha.spec file. If you have
%bcond_with ceph
%global use_fsal_ceph %{on_off_switch ceph}
in your spec file, you won't get ceph by default. If you have
"%bcond_without ceph" then it should build ceph fsal.
The code in src/CMakeLists.txt does seem to gene
I'm working on an automated build script for building Ganesha for Ceph in a
build farm. I am having trouble understanding how to select the cmake
options for make rpm. No matter what I specify in cmake when I set up the
repo, it winds up building FSAL_VFS, FSAL_XFS, FSAL_PROXY, FSAL_NULL, and
FSAL_
> -Original Message-
> From: Marc Eshel [mailto:es...@us.ibm.com]
> Sent: Thursday, August 25, 2016 2:35 PM
> To: Frank Filz
> Cc: 'NFS Ganesha Developers'
> Subject: RE: Change in ffilz/nfs-ganesha[next]: Add blocking locks to
multi-fd.
>
> "Frank Filz" wrote on 08/25/2016 02:23:39 P
"Frank Filz" wrote on 08/25/2016 02:23:39 PM:
> From: "Frank Filz"
> To: Marc Eshel/Almaden/IBM@IBMUS
> Cc: "'NFS Ganesha Developers'"
> Date: 08/25/2016 02:23 PM
> Subject: RE: Change in ffilz/nfs-ganesha[next]: Add blocking locks
> to multi-fd.
>
> > > Since you already have capability to p
> > Since you already have capability to pass a lockowner key to the
> > kernel,
> you
> > don't necessarily need a separate fd for each lock owner, so instead
> > of having an open fd associated with each lock stateid, you could just
> > use
> the
> > fd associated with the open stateid.
>
> How
"Frank Filz" wrote on 08/25/2016 11:48:45 AM:
> From: "Frank Filz"
> To: Marc Eshel/Almaden/IBM@IBMUS
> Cc: "'NFS Ganesha Developers'"
> Date: 08/25/2016 11:49 AM
> Subject: RE: Change in ffilz/nfs-ganesha[next]: Add blocking locks
> to multi-fd.
>
> > "Frank Filz" wrote on 08/25/2016 11:01:
> "Frank Filz" wrote on 08/25/2016 11:01:37 AM:
>
> > From: "Frank Filz"
> > To: Marc Eshel/Almaden/IBM@IBMUS
> > Cc: "'NFS Ganesha Developers'"
> >
> > Date: 08/25/2016 11:01 AM
> > Subject: RE: Change in ffilz/nfs-ganesha[next]: Add blocking locks to
> > multi-fd.
> >
> > > I am not sure of t
"Frank Filz" wrote on 08/25/2016 11:01:37 AM:
> From: "Frank Filz"
> To: Marc Eshel/Almaden/IBM@IBMUS
> Cc: "'NFS Ganesha Developers'"
> Date: 08/25/2016 11:01 AM
> Subject: RE: Change in ffilz/nfs-ganesha[next]: Add blocking locks
> to multi-fd.
>
> > I am not sure of the logic in this secti
> I am not sure of the logic in this section of code in FSAL/commonlib.c
> fsal_find_fd()
> but the lock fails because the openflags is zero before and after the &
> FSAL_O_RDWR; The lock is write lock and the open was not done for write.
> If I change it to openflags = related_fd->openflags | FSAL
Hi Frank,
I am not sure of the logic in this section of code in FSAL/commonlib.c
fsal_find_fd()
but the lock fails because the openflags is zero before and after the &
FSAL_O_RDWR;
The lock is write lock and the open was not done for write.
If I change it to openflags = related_fd->openflags |
>From Patrice LUCAS :
Patrice LUCAS has uploaded a new change for review.
https://review.gerrithub.io/288895
Change subject: Switch PrivilegedPort default from false to true
..
Switch PrivilegedPort default from false to true
12 matches
Mail list logo
