Change in ...nfs-ganesha[next]: GPFS: symlink: Use fsal_internal_close() to close FDs
by Madhu Thorat (GerritHub)
Madhu Thorat has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/471377 )
Change subject: GPFS: symlink: Use fsal_internal_close() to close FDs
......................................................................
GPFS: symlink: Use fsal_internal_close() to close FDs
In GPFS FSAL code, fsal_internal_handle2fd() is called to
open FD for symbolic links. fsal_internal_handle2fd()
increments the open_fd_count (global file descriptor counter).
But close() is called to close FDs for symbolic link, and
open_fd_count is not decremented.
To fix this we now call GPFS FSAL specific fsal_internal_close()
which takes care of closing the FD and decrementing the
open_fd_count as well.
Change-Id: Idd38be334dfa4ac83ae9f1e5dfbbc3f1af5225a3
Signed-off-by: Madhu Thorat <madhu.punjabi(a)in.ibm.com>
---
M src/FSAL/FSAL_GPFS/fsal_symlinks.c
1 file changed, 3 insertions(+), 3 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/77/471377/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/471377
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: Idd38be334dfa4ac83ae9f1e5dfbbc3f1af5225a3
Gerrit-Change-Number: 471377
Gerrit-PatchSet: 1
Gerrit-Owner: Madhu Thorat <madhu.punjabi(a)in.ibm.com>
Gerrit-MessageType: newchange
5 years, 2 months
CfP: Software Defined Storage devroom at FOSDEM 2020
by Niels de Vos
FOSDEM is a free software event that offers open source communities a
place to meet, share ideas and collaborate. It is renown for being
highly developer- oriented and brings together 8000+ participants from
all over the world. It is held in the city of Brussels (Belgium).
FOSDEM 2020 will take place during the weekend of February 1st-2nd 2020.
More details about the event can be found at http://fosdem.org/
** Call For Participation
The Software Defined Storage devroom will go into it's fourth round for
talks around Open Source Software Defined Storage projects, management
tools and real world deployments.
Presentation topics could include but are not limited too:
- Your work on a SDS project like Ceph, Gluster, OpenEBS or LizardFS
- Your work on or with SDS related projects like SWIFT or Container
Storage Interface
- Management tools for SDS deployments
- Monitoring tools for SDS clusters
** Important dates:
- Nov 24th 2019: submission deadline for talk proposals
- Dec 15th 2019: announcement of the final schedule
- Feb 2nd 2020: Software Defined Storage dev room
Talk proposals will be reviewed by a steering committee:
- Niels de Vos (OpenShift Container Storage Developer - Red Hat)
- Jan Fajerski (Ceph Developer - SUSE)
- Kai Wagner (SUSE)
- Mike Perez (Ceph Community Manager, Red Hat)
Use the FOSDEM 'pentabarf' tool to submit your proposal:
https://penta.fosdem.org/submission/FOSDEM20
- If necessary, create a Pentabarf account and activate it. Please
reuse your account from previous years if you have already created it.
https://penta.fosdem.org/user/new_account/FOSDEM20
- In the "Person" section, provide First name, Last name (in the
"General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field
in the "Description" tab).
- Submit a proposal by clicking on "Create event".
- Important! Select the "Software Defined Storage devroom" track (on the
"General" tab).
- Provide the title of your talk ("Event title" in the "General" tab).
- Provide a description of the subject of the talk and the intended
audience (in the "Abstract" field of the "Description" tab)
- Provide a rough outline of the talk or goals of the session (a short
list of bullet points covering topics that will be discussed) in the
"Full description" field in the "Description" tab
- Provide an expected length of your talk in the "Duration" field.
Please consider at least 5 minutes of discussion into your proposal
plus allow 5 minutes for the handover to the next presenter.
Suggested talk length would be 20+5+5 and 45+10+5 minutes. Note that
short talks have a preference so that more topics can be presented
during the day.
** Recording of talks
The FOSDEM organizers plan to have live streaming and recording fully
working, both for remote/later viewing of talks, and so that people can
watch streams in the hallways when rooms are full. This requires
speakers to consent to being recorded and streamed. If you plan to be a
speaker, please understand that by doing so you implicitly give consent
for your talk to be recorded and streamed. The recordings will be
published under the same license as all FOSDEM content (CC-BY).
Hope to hear from you soon! And please forward this announcement.
If you have any further questions, please write to the mailinglist at
storage-devroom(a)lists.fosdem.org and we will try to answer as soon as
possible.
Thanks!
5 years, 2 months
Announce Push of V3.0-rc2
by Frank Filz
Branch next
Tag:V3.0-rc2
NOTE: This should fix issues with cthon04 failing
NOTE: This release includes an ntirpc pullup, please update your submodules
Release Highlights
* NTIRPC - Fix svc_request() API
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
f65ee99 Frank S. Filz V3.0-rc2
04b4b25 Daniel Gryniewicz NTIRPC - Fix svc_request() API
5 years, 2 months
Change in ...nfs-ganesha[next]: NTIRPC - Fix svc_request() API
by Daniel Gryniewicz (GerritHub)
Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/470992 )
Change subject: NTIRPC - Fix svc_request() API
......................................................................
NTIRPC - Fix svc_request() API
The svc_request() API was a-symmetric. It exepected the alloc callback
to refcount the xprt, but it released the ref itself. Fix it to expect
the free callback to release this ref, and make the appropriate change
in Ganesha
Change-Id: Ic830d1ba83ea860f6693dd382c6327fdfb004712
Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com>
---
M src/MainNFSD/nfs_rpc_dispatcher_thread.c
M src/libntirpc
2 files changed, 3 insertions(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/92/470992/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/470992
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: Ic830d1ba83ea860f6693dd382c6327fdfb004712
Gerrit-Change-Number: 470992
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com>
Gerrit-MessageType: newchange
5 years, 2 months
Announce Push of V3.0-rc1
by Frank Filz
Branch next
Tag:V3.0-rc1
NOTE: In case you feel like you got lost in the space-time contunum, we
decided to jump to 3.0 instead of 2.9 due to the significance of features
in this release and we didn't want to someday be doing V2.25 and folks
wondering what the 2. prefix is for...
NOTE: This release includes an ntirpc pullup, please update your submodules
Release Highlights
* Use xdr_putbufs for readir responses
* Use struct attrlist for NFSv3 attributes
* PROXY: use MAXNAMLEN instead of sizeof(name)
* MOUNT: Add mnt3_ prefix to common typedef names
* Only return OPEN_DELEGATE_NONE_EXT if delegations WANTed
* ntirpc pullup to remove error messages for nfs3 readdir
* Remove useless pointer variable.
* use alloca due to &array == array
* Per client and per export stats
* FSAL_GLUSTER: Improving fd handling during OPEN and COMMIT
* fix for race condition between fridgethr_destroy and fridgethr_freeze
* Allow system NTIRPC installed in a prefix
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
fa48ca1 Frank S. Filz V3.0-rc1
069e2e7 Daniel Gryniewicz Allow system NTIRPC installed in a prefix
2f7a1d8 Koen Struyve fix for race condition between fridgethr_destroy and
fridgethr_freeze
7eb379f Soumya Koduri FSAL_GLUSTER: Improving fd handling during OPEN and
COMMIT
6f5614c Sachin Punadikar Per client and per export stats
20dd518 Yang Ruifeng use alloca due to &array == array
fbb42c2 Xi Jinyu Remove useless pointer variable.
1b1a027 Frank S. Filz ntirpc pullup to remove error messages for nfs3
readdir
1635ff6 Frank S. Filz Only return OPEN_DELEGATE_NONE_EXT if delegations
WANTed
2810b4f Frank S. Filz MOUNT: Add mnt3_ prefix to common typedef names
7201c95 Frank S. Filz PROXY: use MAXNAMLEN instead of sizeof(name)
f6edd32 Frank S. Filz Make NFSv4 READDIR use xdr_putbuffs
ca84db5 Frank S. Filz Make NFSv3 READDIR use xdr_putbuffs
dae4aee Frank S. Filz Change nfs3_FSALattr_To_Fattr to nfs3_Fixup_FSALattr
to save copy
1b16781 Frank S. Filz Use struct attrlist for NFSv3 attributes
5 years, 2 months
Re: [nfsv4] xattr or COPY implementations
by Frank Filz
> Aside from submitting the patches you mention, I also fixed the nfs-ganesha
> implementation (that was based on an earlier draft of the spec, and did not have
> VFS backend support).
>
> I haven't had time to clean up and submit the patches, but I can probably make
> them available by next week if someone wants to use it during a bikeathon. I
> used these nfs-ganesha changes for initial testing of the Linux kernel client side.
>
> Frank
If you have these ready, we should be able to get some testing. Kaleb Keithley will be there with a nfs-ganesha setup with most of the FSALs running.
Frank
> On 10/9/19, 10:45 AM, "nfsv4 on behalf of J. Bruce Fields" <nfsv4-
> bounces(a)ietf.org on behalf of bfields(a)fieldses.org> wrote:
>
> There are outstanding Linux kernel client and server patches for xattrs and for
> server-to-server COPY.
>
> Are there any other implementations released or in progress? Will they be
> available for testing at the bakeathon next week? If not, do you expect them to
> be at another event in the future?
>
> --b.
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4(a)ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4(a)ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
5 years, 2 months
Dumping Netezza to nfs-ganesha
by Satish Chandra Kilaru
Hi All,
I am using nfs-ganesha 2.6.3. I am dumping Netezza to a Linux machine running nfs-ganesha. Netezza writes data in 1MB chunks. After each write it checks size of file. After dumping some data it failed saying that expected size is 106MB. But the file size is 104MB.
Nfs-Ganesha debug logs indicated that one of the workers processed a getattr RPC (supposed to have been sent after writing 104MB) after receiving write RPC for 106MB but before it was written to disk.
Is this valid behavior from nfs-ganesha? Are there any settings (on nfs-client or on nfs-ganesha) to make sure operations on a given file are processed in the order they are received?
I have seen another weird problem. I have not got a chance to check logs for it yet. My application creates a temp file, writes small data (10K) to it, closes the file and then renames it. This rename failed with ENOEXIST. I see that temp file is indeed present. Based on my observation with Netezza I am suspecting that that rename was processed before the temp file create RPC was processed. Could that be possible?
--Satish
--Satish
5 years, 2 months
Change in ...nfs-ganesha[next]: Allow system NTIRPC installed in a prefix
by Daniel Gryniewicz (GerritHub)
Daniel Gryniewicz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/470937 )
Change subject: Allow system NTIRPC installed in a prefix
......................................................................
Allow system NTIRPC installed in a prefix
If NTIRPC was installed in a non-standard prefix, then Ganesha's build
couldn't find it. Fix this, so it works both ways.
Change-Id: I250bb75ad12133069e6b1141616ce2f1f4bdcfc2
Signed-off-by: Daniel Gryniewicz <dang(a)redhat.com>
---
M src/CMakeLists.txt
M src/cmake/modules/FindNTIRPC.cmake
2 files changed, 51 insertions(+), 11 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/37/470937/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/470937
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: I250bb75ad12133069e6b1141616ce2f1f4bdcfc2
Gerrit-Change-Number: 470937
Gerrit-PatchSet: 1
Gerrit-Owner: Daniel Gryniewicz <dang(a)redhat.com>
Gerrit-MessageType: newchange
5 years, 2 months
Re: [Nfs-ganesha-devel] 2.7.3 with CEPH_FSAL Crashing
by Daniel Gryniewicz
This is not one I've seen before, and a quick look at the code looks
strange. The only assert in that bit is asserting the parent is a
directory, but the parent directory is not something that was passed in
by Ganesha, but rather something that was looked up internally in
libcephfs. This is beyond my expertise, at this point. Maybe some ceph
logs would help?
Daniel
On 7/15/19 10:54 AM, David C wrote:
> This list has been deprecated. Please subscribe to the new devel list at lists.nfs-ganesha.org.
>
>
> Hi All
>
> I'm running 2.7.3 using the CEPH FSAL to export CephFS (Luminous), it
> ran well for a few days and crashed. I have a coredump, could someone
> assist me in debugging this please?
>
> (gdb) bt
> #0 0x00007f04dcab6207 in raise () from /lib64/libc.so.6
> #1 0x00007f04dcab78f8 in abort () from /lib64/libc.so.6
> #2 0x00007f04d2a9d6c5 in ceph::__ceph_assert_fail(char const*, char
> const*, int, char const*) () from /usr/lib64/ceph/libceph-common.so.0
> #3 0x00007f04d2a9d844 in ceph::__ceph_assert_fail(ceph::assert_data
> const&) () from /usr/lib64/ceph/libceph-common.so.0
> #4 0x00007f04cc807f04 in Client::_lookup_name(Inode*, Inode*, UserPerm
> const&) () from /lib64/libcephfs.so.2
> #5 0x00007f04cc81c41f in Client::ll_lookup_inode(inodeno_t, UserPerm
> const&, Inode**) () from /lib64/libcephfs.so.2
> #6 0x00007f04ccadbf0e in create_handle (export_pub=0x1baff10,
> desc=<optimized out>, pub_handle=0x7f0470fd4718,
> attrs_out=0x7f0470fd4740) at
> /usr/src/debug/nfs-ganesha-2.7.3/FSAL/FSAL_CEPH/export.c:256
> #7 0x0000000000523895 in mdcache_locate_host (fh_desc=0x7f0470fd4920,
> export=export@entry=0x1bafbf0, entry=entry@entry=0x7f0470fd48b8,
> attrs_out=attrs_out@entry=0x0)
> at
> /usr/src/debug/nfs-ganesha-2.7.3/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:1011
> #8 0x000000000051d278 in mdcache_create_handle (exp_hdl=0x1bafbf0,
> fh_desc=<optimized out>, handle=0x7f0470fd4900, attrs_out=0x0) at
> /usr/src/debug/nfs-ganesha-2.7.3/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1578
> #9 0x000000000046d404 in nfs4_mds_putfh
> (data=data@entry=0x7f0470fd4ea0) at
> /usr/src/debug/nfs-ganesha-2.7.3/Protocols/NFS/nfs4_op_putfh.c:211
> #10 0x000000000046d8e8 in nfs4_op_putfh (op=0x7f03effaf1d0,
> data=0x7f0470fd4ea0, resp=0x7f03ec1de1f0) at
> /usr/src/debug/nfs-ganesha-2.7.3/Protocols/NFS/nfs4_op_putfh.c:281
> #11 0x000000000045d120 in nfs4_Compound (arg=<optimized out>,
> req=<optimized out>, res=0x7f03ec1de9d0) at
> /usr/src/debug/nfs-ganesha-2.7.3/Protocols/NFS/nfs4_Compound.c:942
> #12 0x00000000004512cd in nfs_rpc_process_request
> (reqdata=0x7f03ee5ed4b0) at
> /usr/src/debug/nfs-ganesha-2.7.3/MainNFSD/nfs_worker_thread.c:1328
> #13 0x0000000000450766 in nfs_rpc_decode_request (xprt=0x7f02180c2320,
> xdrs=0x7f03ec568ab0) at
> /usr/src/debug/nfs-ganesha-2.7.3/MainNFSD/nfs_rpc_dispatcher_thread.c:1345
> #14 0x00007f04df45d07d in svc_rqst_xprt_task (wpe=0x7f02180c2538) at
> /usr/src/debug/nfs-ganesha-2.7.3/libntirpc/src/svc_rqst.c:769
> #15 0x00007f04df45d59a in svc_rqst_epoll_events (n_events=<optimized
> out>, sr_rec=0x4bb53e0) at
> /usr/src/debug/nfs-ganesha-2.7.3/libntirpc/src/svc_rqst.c:941
> #16 svc_rqst_epoll_loop (sr_rec=<optimized out>) at
> /usr/src/debug/nfs-ganesha-2.7.3/libntirpc/src/svc_rqst.c:1014
> #17 svc_rqst_run_task (wpe=0x4bb53e0) at
> /usr/src/debug/nfs-ganesha-2.7.3/libntirpc/src/svc_rqst.c:1050
> #18 0x00007f04df465123 in work_pool_thread (arg=0x7f044c0008c0) at
> /usr/src/debug/nfs-ganesha-2.7.3/libntirpc/src/work_pool.c:181
> #19 0x00007f04dda05dd5 in start_thread () from /lib64/libpthread.so.0
> #20 0x00007f04dcb7dead in clone () from /lib64/libc.so.6
>
> Package versions:
>
> nfs-ganesha-2.7.3-0.1.el7.x86_64
> nfs-ganesha-ceph-2.7.3-0.1.el7.x86_64
> libcephfs2-14.2.1-0.el7.x86_64
> librados2-14.2.1-0.el7.x86_64
>
> I notice in my Ceph log I have a bunch of slow requests around the time
> it went down, I'm not sure if it's a symptom of Ganesha segfaulting or
> if it was a contributing factor.
>
> Thanks,
> David
>
>
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
5 years, 2 months