Announce Push of V4-dev.22
by Frank Filz
Branch next
Tag:V4-dev.22
Merge Highlights
* bugfix: Resolve compilation fail when acl/libacl.h was not found
* Always set the wcc attributes in NFSv3 setattr replies
* spec: add libacl-devel to CephFS BuildRequires
* systemd: revised drop-in conf file handling
* MDCACHE: add lru release entries process
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
efb9445 Frank S. Filz V4-dev.22
b91fe03 sepia-liu MDCACHE: add lru release entries process
0c0d143 Kaleb S. KEITHLEY systemd: revised drop-in conf file handling
8f01a5d Thomas Serlin spec: add libacl-devel to CephFS BuildRequires
23454db David Hedberg Always set the wcc attributes in NFSv3 setattr replies
8eda102 Luo Muyao bugfix: Resolve compilation fail when acl/libacl.h was not
found
2 years, 11 months
should we make nfs-ganesha an optional part of a ceph build?
by Jeff Layton
(I sent this to a smaller list of folks yesterday, but I think it
probably warrants wider discussion).
Recently Varsha added the necessary infrastructure to bring up
nfs-ganesha via vstart.sh. The current implementation requires that
ganesha already be installed on the box (usually via distro packaging),
but that poses a bit of a problem.
A distro ganesha package will have likely been built vs. a completely
different version of libcephfs and librados. Even if you build right off
of ceph master branch, you won't get the benefit of any recent client
bugfixes when you want to test ganesha. You'd have to build new ganesha
packages, install them, etc.
I think we ought to consider making a nfs-ganesha build an optional part
of a ceph build (maybe enable it with cmake -DNFS_GANESHA=ON or
something).
It doesn't take very long to build it (typically only a minute or two on
my box), and we could disable the parts that ceph doesn't care about
(other FSALs primarily). We could also have vstart just error out when
you run it with NFS=X on a build that didn't have ganesha enabled.
OTOH, the potential downside here is that it'll likely add other build-
time dependencies, and would require some extra cmake or scripting
wizardry. Nothing insurmountable, but it might represent a maintenance
burden going forward, particularly for something that's basically only
going to be used for vstart.
I'm also not sure how we'd do this in practice. I don't think you can do
optional submodules, so we might have to look at other methods of
pulling in the ganesha tree, or just live with it as a submodule that
only gets used when ganesha is enabled.
Thoughts?
--
Jeff Layton <jlayton(a)redhat.com>
2 years, 11 months
Change in ...nfs-ganesha[next]: [GPFS] Fix to let GPFS upcall thread exit at ganesha startup
by Madhu Thorat (GerritHub)
Hello Malahal,
I'd like you to do a code review. Please visit
https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495993
to review the following change.
Change subject: [GPFS] Fix to let GPFS upcall thread exit at ganesha startup
......................................................................
[GPFS] Fix to let GPFS upcall thread exit at ganesha startup
Currently during startup if GPFSFSAL_UP_Thread() gets called, it
waits in nfs_init_wait() for init to complete. But if during startup
gpfs_unclaim_filesystem() gets called, then the main thread may hang
at pthread_join() for GPFS upcall thread, if the thread is waiting in
nfs_init_wait().
To avoid this made use of 'stop_thread' variable in
'struct gpfs_filesystem', which is set to 'true' prior to calling
pthread_join() in gpfs_unclaim_filesystem(). Also made changes to
allow to pass timeout value to nfs_init_wait() which is now called
in GPFSFSAL_UP_Thread() in while(1) loop, and after nfs_init_wait()
completes if gpfs_fs->stop_thread==true then we return.
Change-Id: I8cdf193ce955cd7248104741927307974d8f0958
Signed-off-by: Madhu Thorat <madhu.punjabi(a)in.ibm.com>
Reviewed-by: Malahal Naineni <malahal(a)us.ibm.com>
---
M src/FSAL/FSAL_GPFS/export.c
M src/FSAL/FSAL_GPFS/fsal_up.c
M src/FSAL/FSAL_GPFS/gpfs_methods.h
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c
M src/MainNFSD/nfs_init.c
M src/include/nfs_init.h
6 files changed, 46 insertions(+), 9 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/93/495993/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495993
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: I8cdf193ce955cd7248104741927307974d8f0958
Gerrit-Change-Number: 495993
Gerrit-PatchSet: 1
Gerrit-Owner: Madhu Thorat <madhu.punjabi(a)in.ibm.com>
Gerrit-Reviewer: Malahal <malahal(a)gmail.com>
Gerrit-MessageType: newchange
2 years, 11 months
Change in ...nfs-ganesha[next]: systemd: revised drop-in conf file handling
by Kaleb KEITHLEY (GerritHub)
Kaleb KEITHLEY has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495955 )
Change subject: systemd: revised drop-in conf file handling
......................................................................
systemd: revised drop-in conf file handling
see https://bugzilla.redhat.com/show_bug.cgi?id=1848208
systemd service file documentation still sucks rocks
This is my current best guess, and at least it doesn't log errors
Change-Id: Iec9847356090e561bfcd5f41a64b35c2e686a3d6
Signed-off-by: Kaleb S. KEITHLEY <kkeithle(a)redhat.com>
---
M src/scripts/systemd/nfs-ganesha-lock.service.debian10
M src/scripts/systemd/nfs-ganesha-lock.service.el8
M src/scripts/systemd/rpc-statd.conf.debian10
M src/scripts/systemd/rpc-statd.conf.el8
4 files changed, 6 insertions(+), 8 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/55/495955/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495955
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: Iec9847356090e561bfcd5f41a64b35c2e686a3d6
Gerrit-Change-Number: 495955
Gerrit-PatchSet: 1
Gerrit-Owner: Kaleb KEITHLEY <kaleb(a)redhat.com>
Gerrit-MessageType: newchange
2 years, 11 months
Change in ...nfs-ganesha[next]: MDCACHE: root_obj must be released before last unexport
by sepia-liu (GerritHub)
sepia-liu has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495911 )
Change subject: MDCACHE: root_obj must be released before last unexport
......................................................................
MDCACHE: root_obj must be released before last unexport
root object must be released before last export is released.
If last export of root_obj is released, just left root object
handle in cache, once the export resource is used through
root_obj->export, NULL pointer used cause to crash such as
obj->export->cmount in deconstruct_handle() of FSAL_CEPH.
So can not remove cih_remove_checked() in mdcache_unexport.
Another case, if the object entry to be root of multiple exports,
here should not unhash and set entry as invalid when the first
export unmount, but unhash in last unexport. So we need to judge.
Change-Id: I0068441f94b6185f3b072391edb8c5ec29ea60ca
Signed-off-by: sepia-liu <liuwei_coder(a)163.com>
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_export.c
1 file changed, 7 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/11/495911/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495911
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: I0068441f94b6185f3b072391edb8c5ec29ea60ca
Gerrit-Change-Number: 495911
Gerrit-PatchSet: 1
Gerrit-Owner: sepia-liu <liuwei_coder(a)163.com>
Gerrit-MessageType: newchange
2 years, 11 months
Change in ...nfs-ganesha[next]: Always set the wcc attributes in NFSv3 setattr replies
by Name of user not set (GerritHub)
david.hedberg(a)zavann.se has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495849 )
Change subject: Always set the wcc attributes in NFSv3 setattr replies
......................................................................
Always set the wcc attributes in NFSv3 setattr replies
A special case was added in 4a3af6df1b46075b80f33e43e3f19fd768e6c43a,
as the wcc was set using attribute information that could be
incomplete if only the file size was modified. In this case, the reply
would be marked as containing no wcc data at all.
The attribute information for the wcc is now fetched using getattr
calls to the FSAL layer and the check should no longer be needed.
Signed-off-by: David Hedberg <david.hedberg(a)zavann.se>
Change-Id: If8584d1b0ddb27ca200af9e85cf2ff11c2d28c2a
---
M src/Protocols/NFS/nfs3_setattr.c
1 file changed, 3 insertions(+), 8 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/49/495849/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495849
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: If8584d1b0ddb27ca200af9e85cf2ff11c2d28c2a
Gerrit-Change-Number: 495849
Gerrit-PatchSet: 1
Gerrit-Owner: david.hedberg(a)zavann.se
Gerrit-MessageType: newchange
2 years, 11 months
Change in ...nfs-ganesha[next]: bugfix: Resolve compilation fail when acl/libacl.h was not found
by MuYao Luo (GerritHub)
MuYao Luo has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495840 )
Change subject: bugfix: Resolve compilation fail when acl/libacl.h was not found
......................................................................
bugfix: Resolve compilation fail when acl/libacl.h was not found
acl/libacl.h is included by posix_acls.h which is out of USE_NFSACL3
condition judgment, We should include it in this conditional statement
to prevent compilation errors.
Change-Id: Id1f0417f40ab635d94a51bc106b936e7b4c6f715
Signed-off-by: Luo Muyao <luo.muyao(a)zte.com.cn>
---
M src/include/nfs_proto_tools.h
1 file changed, 1 insertion(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/40/495840/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/495840
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: Id1f0417f40ab635d94a51bc106b936e7b4c6f715
Gerrit-Change-Number: 495840
Gerrit-PatchSet: 1
Gerrit-Owner: MuYao Luo <luo.muyao(a)zte.com.cn>
Gerrit-MessageType: newchange
2 years, 11 months
Agile Practices
by Frank Filz
Several of us from Red Hat (Daniel, Kaleb, Matt, and I) recently took some
agile training. We would like to use some of that in improving how we manage
development priorities and response to issues. Our training presented two
methodologies, Scrum and Kanban. We generally preferred Kanban and would
like to open a community discussion. We will take some time on the community
call tomorrow.
In the meantime, I started exploring how we could use github to help manage,
and realized the "projects" that Supriti introduced us to a couple years ago
are Kanban boards. Playing around, it's real easy to manage the backlog and
moving cards through to completion, and additionally, issues can be turned
into cards, or issues created from cards.
The way I see this working:
Cards can be used to manage the backlog and show progress on items (if an
issue is also a card, the column it's in shows in the issue making it easy
to cross reference).
Issues are easy for outsiders to raise issues, they also provide a comment
stream for discussion (non-issue cards can be edited, but that's not a good
way to keep a conversation). Issues also provide labels which we can use to
indicate priority or follow a github suggestion of labelling "good for
beginners" issues. Issues can also be assigned to individuals (though I
think you need to be added to the nfs-ganesha project to be assigned
issues).
I'd love it if there was integration with gerrithub, but I haven't found any
yet, but we can certainly cross link between issues and gerrithib patches.
Given gerrithub's management of multiple versions of patches and making the
entire comment history easily available, I prefer to use gerrithub for patch
submission even though github pull requests CAN be integrated with the
Kanban project.
I've created a Ganesha 4 project, though I'm not sure we want to necessarily
have a project per release, maybe just a single project. Also, I'm not sure
if we can link the project to the ntirpc repo also, or if we need to have a
separate project for it (or just use soft links, but since ntirpc DOES use
github pull requests, it would be nice to have that integration into the
Kanban project.
Please take some time to play around before tomorrow's meeting. Feel free to
create a card for something you're working on, and possibly turning it into
an issue, and play around with linking an issue you're commenting on to the
project. Let us know what you think of this idea.
Thanks
Frank
2 years, 11 months