Change in ...nfs-ganesha[next]: NFSv4.1 CLOSE/LOCK race fix
by Malahal (GerritHub)
Malahal has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/497940 )
Change subject: NFSv4.1 CLOSE/LOCK race fix
......................................................................
NFSv4.1 CLOSE/LOCK race fix
Clients (buggy?) may send CLOSE and LOCK requests at the sametime for
the same open state. We shouldn't add lock state to an already closed
open state. Fail the lock request if the open state is closed.
Change-Id: I0a2b781abdb511753d2730ac0dcb9c4affca525d
Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com>
---
M src/Protocols/NFS/nfs4_op_lock.c
1 file changed, 22 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/40/497940/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/497940
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: I0a2b781abdb511753d2730ac0dcb9c4affca525d
Gerrit-Change-Number: 497940
Gerrit-PatchSet: 1
Gerrit-Owner: Malahal <malahal(a)gmail.com>
Gerrit-MessageType: newchange
3 years, 9 months
Announce Push of V4-dev.25
by Frank Filz
Branch next
Tag:V4-dev.25
Merge Highlights
* systemd: missing [Unit] line in rpc-statd.conf(.el8)
* Serialize innetgr() calls as a workaround
* dbus: remove gobject imports
* Make minimum svc worker threads configurable
* Send correct fsid for NFSv3
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
a1b1454 Frank S. Filz V4-dev.25
598ab4f Ashish Sangwan Send correct fsid for NFSv3
2da8df6 Malahal Naineni Make minimum svc worker threads configurable
bdfb18e Malahal Naineni dbus: remove gobject imports
c30f4a0 Malahal Naineni Serialize innetgr() calls as a workaround
5f3450a Kaleb S. KEITHLEY systemd: missing [Unit] line in
rpc-statd.conf(.el8)
3 years, 9 months
Change in ...nfs-ganesha[next]: Send correct fsid for NFSv3
by Ashish Sangwan (GerritHub)
Ashish Sangwan has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/497875 )
Change subject: Send correct fsid for NFSv3
......................................................................
Send correct fsid for NFSv3
1b1678 caused regression and we are now sending fsid.major as
64bit fsid in case of NFSv3 while what we actually should send
is the squashed fsid fsid3.
Signed-off-by: Ashish Sangwan <ashishsangwan2(a)gmail.com>
Change-Id: I60729e5eb304d5430bc4036b43393a912c33cb8d
---
M src/Protocols/XDR/xdr_nfs23.c
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/75/497875/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/497875
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: I60729e5eb304d5430bc4036b43393a912c33cb8d
Gerrit-Change-Number: 497875
Gerrit-PatchSet: 1
Gerrit-Owner: Ashish Sangwan <ashishsangwan2(a)gmail.com>
Gerrit-MessageType: newchange
3 years, 9 months
Re: NFSV4 (FSAL_VFS) multi-clients copy large file: Input/output error with version V3-stable
by Daniel Gryniewicz
Please send messages like this to the mailing list (
devel(a)lists.nfs-ganesha.org), as other people might have ideas that I
don't.
Unfortunately, I/O error is a generic error, and doesn't tell us much of
anything. We'd need an error from the logs on either the client or server,
or a packet dump to be able to tell what's going on.
Daniel
On Thu, Jul 9, 2020 at 3:56 AM Leave <yuanzhu1987(a)qq.com> wrote:
> Hi，
>
> When I use the nfs-ganesha with V3-stable, I found that if we use multiple
> clients(like 5 clients on different PC based on Vmware machine) to copy big
> file(like 1G) at the same time by the NFSv4, the "Input/output error" is
> occured on the client. We cannot find any log about the error in the log of
> the server.
> But if we copy the file one by one, this error is not seen. we tried many
> times, include xfs or ext4, the error occured *with high probability*
> when: 1.multi-clients copy large files at the same time 2.mount with
> NFSV4
> And if we use NFSv3, this error is not seen.
> Could you please give us some clue about this problem?
> ps: we used FSAL_VFS.
>
> error(some clients didnot occured, but some did with high probability)：
>
> [root@localhost kpfadmin]# cp 1G t2/
> cp: error writing 't2/1G': Input/output error
> cp: failed to close 't2/1G': Input/output error
>
> OS:
> Centos 8.1-1911
> Linux localhost.localdomain 4.18.0-147.el8.x86_64 #1 SMP Wed Dec 4
> 21:51:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>
> client mount like:
>
> 10.10.1.184: mount -t nfs4 10.10.1.183:/t3 t4/ 10.10.1.185: mount -t nfs4 10.10.1.183:/t4 t4/10.10.1.186: mount -t nfs4 10.10.1.183:/t5 t5/10.10.1.187: mount -t nfs4 10.10.1.183:/t5 t5/
>
> server(ganesha.conf):
>
> ###################################################
> #
> # Ganesha Config Example
> #
> # This is a commented example configuration file for Ganesha. It is not
> # complete, but only has some common configuration options. See the man pages
> # for complete documentation.
> #
> ###################################################
>
> ## These are core parameters that affect Ganesha as a whole.
> #NFS_CORE_PARAM {
> ## Allow NFSv3 to mount paths with the Pseudo path, the same as NFSv4,
> ## instead of using the physical paths.
> #mount_path_pseudo = true;
>
> ## Configure the protocols that Ganesha will listen for. This is a hard
> ## limit, as this list determines which sockets are opened. This list
> ## can be restricted per export, but cannot be expanded.
> #Protocols = 3,4,9P;
> #}
>
> ## These are defaults for exports. They can be overridden per-export.
> #EXPORT_DEFAULTS {
> ## Access type for clients. Default is None, so some access must be
> ## given either here or in the export itself.
> #Access_Type = RW;
> #}
>
> ## Configure settings for the object handle cache
> #MDCACHE {
> ## The point at which object cache entries will start being reused.
> #Entries_HWMark = 100000;
> #}
>
> EXPORT
> {
> ## Export Id (mandatory, each EXPORT must have a unique Export_Id)
> Export_Id = 1001;
>
> ## Exported path (mandatory)
> Path = /home/kpfadmin/t1;
>
> ## Pseudo Path (required for NFSv4 or if mount_path_pseudo = true)
> Pseudo = /t1;
>
> ## Restrict the protocols that may use this export. This cannot allow
> ## access that is denied in NFS_CORE_PARAM.
> Protocols = 3,4;
>
> ## Access type for clients. Default is None, so some access must be
> ## given. It can be here, in the EXPORT_DEFAULTS, or in a CLIENT block
> Access_Type = RW;
>
> ## Whether to squash various users.
> Squash = root_squash;
>
> ## Allowed security types for this export
> #Sectype = sys,krb5,krb5i,krb5p;
>
> ## Exporting FSAL
> FSAL {
> Name = VFS;
> }
> }
>
>
>
> ## Configure an export for some file tree
> EXPORT
> {
> ## Export Id (mandatory, each EXPORT must have a unique Export_Id)
> Export_Id = 2;
>
> ## Exported path (mandatory)
> Path = /home/kpfadmin/t2;
>
> ## Pseudo Path (required for NFSv4 or if mount_path_pseudo = true)
> Pseudo = /t2;
>
> ## Restrict the protocols that may use this export. This cannot allow
> ## access that is denied in NFS_CORE_PARAM.
> Protocols = 3,4;
>
> ## Access type for clients. Default is None, so some access must be
> ## given. It can be here, in the EXPORT_DEFAULTS, or in a CLIENT block
> Access_Type = RW;
>
> ## Whether to squash various users.
> Squash = root_squash;
>
> ## Allowed security types for this export
> #Sectype = sys,krb5,krb5i,krb5p;
>
> ## Exporting FSAL
> FSAL {
> Name = VFS;
> }
> }
>
> ## Configure an export for some file tree
> EXPORT
> {
> ## Export Id (mandatory, each EXPORT must have a unique Export_Id)
> Export_Id = 3;
>
> ## Exported path (mandatory)
> Path = /home/kpfadmin/t3;
>
> ## Pseudo Path (required for NFSv4 or if mount_path_pseudo = true)
> Pseudo = /t3;
>
> ## Restrict the protocols that may use this export. This cannot allow
> ## access that is denied in NFS_CORE_PARAM.
> Protocols = 3,4;
>
> ## Access type for clients. Default is None, so some access must be
> ## given. It can be here, in the EXPORT_DEFAULTS, or in a CLIENT block
> Access_Type = RW;
>
> ## Whether to squash various users.
> Squash = root_squash;
>
> ## Allowed security types for this export
> #Sectype = sys,krb5,krb5i,krb5p;
>
> ## Exporting FSAL
> FSAL {
> Name = VFS;
> }
> }
>
> ## Configure an export for some file tree
> EXPORT
> {
> ## Export Id (mandatory, each EXPORT must have a unique Export_Id)
> Export_Id = 4;
>
> ## Exported path (mandatory)
> Path = /home/kpfadmin/t4;
>
> ## Pseudo Path (required for NFSv4 or if mount_path_pseudo = true)
> Pseudo = /t4;
>
> ## Restrict the protocols that may use this export. This cannot allow
> ## access that is denied in NFS_CORE_PARAM.
> Protocols = 3,4;
>
> ## Access type for clients. Default is None, so some access must be
> ## given. It can be here, in the EXPORT_DEFAULTS, or in a CLIENT block
> Access_Type = RW;
>
> ## Whether to squash various users.
> Squash = root_squash;
>
> ## Allowed security types for this export
> #Sectype = sys,krb5,krb5i,krb5p;
>
> ## Exporting FSAL
> FSAL {
> Name = VFS;
> }
> }
>
> ## Configure an export for some file tree
> EXPORT
> {
> ## Export Id (mandatory, each EXPORT must have a unique Export_Id)
> Export_Id = 5;
>
> ## Exported path (mandatory)
> Path = /home/kpfadmin/t5;
>
> ## Pseudo Path (required for NFSv4 or if mount_path_pseudo = true)
> Pseudo = /t5;
>
> ## Restrict the protocols that may use this export. This cannot allow
> ## access that is denied in NFS_CORE_PARAM.
> Protocols = 3,4;
>
> ## Access type for clients. Default is None, so some access must be
> ## given. It can be here, in the EXPORT_DEFAULTS, or in a CLIENT block
> Access_Type = RW;
>
> ## Whether to squash various users.
> Squash = root_squash;
>
> ## Allowed security types for this export
> #Sectype = sys,krb5,krb5i,krb5p;
>
> ## Exporting FSAL
> FSAL {
> Name = VFS;
> }
> }
>
> ## Configure logging. Default is to log to Syslog. Basic logging can also be
> ## configured from the command line
> LOG {
> ## Default log level for all components
> Default_Log_Level = WARN;
>
> ## Configure per-component log levels.
> #Components {
> #FSAL = INFO;
> #NFS4 = EVENT;
> #}
>
> ## Where to log
> Facility {
> name = FILE;
> destination = "/var/log/ganesha.log";
> enable = active;
> }
> }
>
>
>
3 years, 9 months
Change in ...nfs-ganesha[next]: systemd: missing [Unit] line in rpc-statd.conf(.el8)
by Kaleb KEITHLEY (GerritHub)
Kaleb KEITHLEY has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/497278 )
Change subject: systemd: missing [Unit] line in rpc-statd.conf(.el8)
......................................................................
systemd: missing [Unit] line in rpc-statd.conf(.el8)
Must have fat-fingered it somehow, because the rpc-statd.conf.debian10
file is correct
Change-Id: I8fdc608f770699b55ae65082e36acd89ddce99d5
Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com>
---
M src/scripts/systemd/rpc-statd.conf.el8
1 file changed, 1 insertion(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/78/497278/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/497278
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: I8fdc608f770699b55ae65082e36acd89ddce99d5
Gerrit-Change-Number: 497278
Gerrit-PatchSet: 1
Gerrit-Owner: Kaleb KEITHLEY <kaleb(a)redhat.com>
Gerrit-MessageType: newchange
3 years, 9 months
Announce Push of V4-dev.24
by Frank Filz
Branch next
Tag:V4-dev.24
Merge Highlights
* Fix shadow-utils requirement on SLES12
* Fix ACL refcount leak
* [GPFS] Fix to let GPFS upcall thread exit at ganesha startup
* In nfs4_op_lock() call state_del_locked() only for new lock state
* selinux: ganesha_use_fusefs tuneable policy, add fs_search_fusefs
* Fix latency calculation of individual compounds.
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
eb87550 Frank S. Filz V4-dev.24
e2773a8 Pradeep Fix latency calculation of individual compounds.
58d464a Kaleb S. KEITHLEY selinux: ganesha_use_fusefs tuneable policy, add
fs_search_fusefs
3fa2daf Madhu Thorat In nfs4_op_lock() call state_del_locked() only for new
lock state
0e4fb74 Madhu Thorat [GPFS] Fix to let GPFS upcall thread exit at ganesha
startup
72d4e63 Malahal Naineni Fix ACL refcount leak
409ae5a Malahal Naineni Fix shadow-utils requirement on SLES12
3 years, 9 months
Callbacks supported with 4.1
by Trishali Nayar
Hi all,
Recently while doing some testing we observed that CB_NOTIFY_LOCK callback
does not seem to supported by Ganesha. Is that understanding correct?
Also, any insights on the 4.1 callbacks that we do support, would be good
to know. The RFC mentions quite a few of them.
Thanks and regards,
Trishali.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Trishali Nayar
IBM Systems
ETZ, Pune.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3 years, 9 months
Re: [NFS-Ganesha-Support] Re: ACL support with NFS-Ganesha V3 and the stability of v4 acl implementation
by Frank Filz
Richacl would definitely help, and Ganesha would be a good place to use it if it ever becomes available, even if only in library filesystems like Cephfs.
Frank
> -----Original Message-----
> From: Rafi Kavungal [mailto:rafi.kavungal@iternity.com]
> Sent: Wednesday, July 1, 2020 5:44 AM
> To: Daniel Gryniewicz <dang(a)redhat.com>; support(a)lists.nfs-ganesha.org;
> devel(a)lists.nfs-ganesha.org
> Subject: [NFS-Ganesha-Support] Re: [NFS-Ganesha-Devel] ACL support with NFS-
> Ganesha V3 and the stability of v4 acl implementation
>
> Thanks Daniel, I will see if we can wait for v4 or I will backport to v3.x .
>
> I can understand that the conversion to posix acl will be a lossy one. I'm also
> looking to ricahcl to address the issue.
>
> Regards
> Rafi KC
>
> -----Original Message-----
> From: Daniel Gryniewicz <dang(a)redhat.com>
> Sent: 01 July 2020 06:07 PM
> To: Rafi Kavungal <rafi.kavungal(a)iternity.com>; support(a)lists.nfs-ganesha.org;
> devel(a)lists.nfs-ganesha.org
> Subject: Re: [NFS-Ganesha-Devel] ACL support with NFS-Ganesha V3 and the
> stability of v4 acl implementation
>
> NFSv3 ACLs were recently added to the 4.x development codebase. It's never,
> as far as I know, been tested with Gluster, but the code is in place, and can be
> used. There's no current timeframe for a 4.0 release, but it's a small, self-
> contained patch, so it's not impossible to backport it to a 3.x version.
>
> NFSv4 ACLs have been available and supported for a long time, they should work
> fine (with the usual caveat that NFSv4 ACLs and POSIX ACLs are not fully
> compatible, so there could be issues if the full NFSv3 ACL semantics are needed).
>
> Daniel
>
> On 7/1/20 3:35 AM, Rafi Kavungal wrote:
> > Hi All,
> >
> > We want to use nfs-ganesha with gluster and we have a requirement to
> > use acl with both v3 and v4. But going through the previous mail
> > archives, I understood that acl is not supported with v3. Is there any
> > chance of acl support with v3 in near future. How easy is to implement this
> feature in v3.
> >
> > An addition question is regarding the stability of acl with v4. Is
> > there any known issues? Is it ready for using it in the production
> > setup. Any users who consumes acl on v4?
> >
> > Any help is much appreciated, Thanks in advance.
> >
> > Rafi KC
> >
> >
> > _______________________________________________
> > Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send
> > an email to devel-leave(a)lists.nfs-ganesha.org
> >
> _______________________________________________
> Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an
> email to support-leave(a)lists.nfs-ganesha.org
3 years, 9 months
Re: ACL support with NFS-Ganesha V3 and the stability of v4 acl implementation
by Daniel Gryniewicz
NFSv3 ACLs were recently added to the 4.x development codebase. It's
never, as far as I know, been tested with Gluster, but the code is in
place, and can be used. There's no current timeframe for a 4.0 release,
but it's a small, self-contained patch, so it's not impossible to
backport it to a 3.x version.
NFSv4 ACLs have been available and supported for a long time, they
should work fine (with the usual caveat that NFSv4 ACLs and POSIX ACLs
are not fully compatible, so there could be issues if the full NFSv3 ACL
semantics are needed).
Daniel
On 7/1/20 3:35 AM, Rafi Kavungal wrote:
> Hi All,
>
> We want to use nfs-ganesha with gluster and we have a requirement to use
> acl with both v3 and v4. But going through the previous mail archives, I
> understood that acl is not supported with v3. Is there any chance of acl
> support with v3 in near future. How easy is to implement this feature in v3.
>
> An addition question is regarding the stability of acl with v4. Is there
> any known issues? Is it ready for using it in the production setup. Any
> users who consumes acl on v4?
>
> Any help is much appreciated, Thanks in advance.
>
> Rafi KC
>
>
> _______________________________________________
> Devel mailing list -- devel(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>
3 years, 9 months
Change in ...nfs-ganesha[next]: In nfs4_op_lock() call state_del_locked() only for new lock state
by Madhu Thorat (GerritHub)
Madhu Thorat has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/496788 )
Change subject: In nfs4_op_lock() call state_del_locked() only for new lock state
......................................................................
In nfs4_op_lock() call state_del_locked() only for new lock state
Currently in nfs4_op_lock() if state_lock() fails, we call
state_del_locked() if arg_LOCK4->locker.new_lock_owner is true.
But when arg_LOCK4->locker.new_lock_owner is true, we may or may
not add a new lock state.
With this change, if there is a new lock state added, then only
we call state_del_locked() if state_lock() fails.
Change-Id: I57b94b5592ca3a4d31c094edba6f7afc443a4d43
Signed-off-by: Madhu Thorat <madhu.punjabi(a)in.ibm.com>
---
M src/Protocols/NFS/nfs4_op_lock.c
1 file changed, 4 insertions(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/88/496788/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/496788
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: I57b94b5592ca3a4d31c094edba6f7afc443a4d43
Gerrit-Change-Number: 496788
Gerrit-PatchSet: 1
Gerrit-Owner: Madhu Thorat <madhu.punjabi(a)in.ibm.com>
Gerrit-MessageType: newchange
3 years, 9 months
