Re: [Nfs-ganesha-devel] Announce GA of Ganesha V2.2.0

[Frank Filz]

> > Wish we had got this stuff in before I tagged V2.2.0 and opened V2.3...
> In fact, those commits have to be the very last one before GA, and I need
> the src/Changelog updated to produce those commits. Once the changelog
> generated, you should have told me that those commits were to be done (or
> do them yourself, for they are pretty simple). Anyway, we will agree on
the
> point that we failed in staying synchronized (we have
> 9 good excuses: each of the timezones between you and me ;-) ).
> We done not release versions frequently enough and we lack of procedure
> for that. This means that we'll do better next time.
> 
> > We need something to automate this stuff, having to put changelog in
> > several places is annoying.
> I do agree on automatizing the process. But there will be changelog in
> different places: I do not see any easy and maintainable way of sharing
> changelogs for rpm and debian packages.
> This is an operation we do two or three times a year, do we need to do
> something complicated ? Let's set up a procedure in the wiki and apply it.
> Different places for changelog is no problem as long as the information is
the
> same.

If the same text is copied in several places, a simple script could take
text and put it into changelogs AND the signed tag.

Things that are infrequent are great for automation because then they are
done the same way all the time even when people have forgotten. Also, if
some new place is added, whoever adds it just needs to add to the automation
script.

Frank


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] rebase oddity

[Frank Filz]

> On 4/24/15 3:08 AM, Dominique Martinet wrote:
> > Yeah, this was meant to be in the V2.2.0 tag but introduced some bug
> > and pruned out.
> >
> This is not mentioned anywhere in this list.  This list is our
communications
> log, not some chat somewhere.
> 
> 
> > I guess the proper way forward that doesn't break anyone's workflow
> > would have been to add an extra commit that reverts it instead of
> > removing the commit, but Frank decided it was ok since the commit was
> > only there for about a day... (basically Frank's test branch)
> >
> Again, the git repository is itself an official history.  I've never
grabbed
> anything from Frank's test branch.  I've only ever pulled from the "next"
> branch.
> 
> Whenever Marc or I or anybody test each others' stuff, we make a
> temporary test branch to throw away afterward.
> 
> 
> > Should probably only tag commits in the nfs-ganesha "reference" tree,
> > where stuff is pushed after testing, so that doesn't happen again?
> > (e.g. it's ok to have reverts in Frank's branches as only devs use it
> > to push, but not in the broader public history)
> >
> Agreed.  But we already had an agreement that "master" is the official
> release branch, and "next" is the official development branch.  After
making
> it to next, it should have had a revert.
> 
> Hopefully, I can rebase -i and delete the errant commit anywhere that
comes
> up again

I'm sorry this happened. I am still trying to figure out how to best use
gerrithub.

Unfortunately there is going to be some growing pains.

In any case though, the nfs-ganesha/next branch is what will be considered
an official "history won't change" repo. I will ALSO attempt to never have
to do that with gerrithub, unfortunately gerrithub doesn't have a way to
make a "test" merge of a bunch of patches. Which means I will have to cherry
pick each patch from gerrithub for my release testing, and THEN, when it all
looks good, will have to do gerrithub cherry pick merges, and THEN retest...

This WILL cause some growing pains, and until I settle out a workable method
that doesn't grow performing the weekly merge significantly from what it
took in the past, I reserve the option to rewrite history rather than revert
patches. I will do my damndest to avoid this, because once I have merged a
patch on gerrithub, the history for that patch is closed... Which means I
can't then comment on why I didn't include it until the submitter
republishes it, whether I revert it or rewrite history.

In the meantime, what will ALSO help tremendously is if other folks ALSO do
verifications, and add a verified +1 in gerrithub (or -1 if it actually
fails in some significant way for you). This will result in fewer issues
discovered when I go to verify the merge.

One awkwardness we are dealing with is that gerrithub really seems to be set
up for the model where perhaps a bunch of patches are submitted, but ONE
patch is accepted and verified at a time. Then everyone else rebases their
patches, and then the next patch is verified and accepted.

Thanks

Frank


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] [Nfs-ganesha-support] Troubles with configuration

[Frank Filz]

> I try to explain - what i've successful mount server with nfsv4 and work
with
> it, but can't do it with nfsv3, and does not matter what FASL i've using
(VFS or
> Ceph) i.e. i don't have problem with NFSv4 and ai can work with ceph by
it, so
> beautiful, but if i try to connect with nfsv3, i've get some problems, and
i just
> try to understand what i can miss _-_
> 
> Yes, i've use V2.2, but i've same problem with V2.1 (it can be something
> debian/ubuntu specific _-_)

Hmm, let's try adding some debug logging (please use V2.2.0), add this to
your config:

LOG
{
COMPONENTS
{
EXPORT=FullDebug;
NFS3=FullDebug;
FSAL=FullDebug;
}
}

That should help us determine where the issue is.

Thanks

Frank

> 2015-04-24 20:04 GMT+03:00 Matt W. Benjamin :
> > Hi,
> >
> > The Ceph FSAL uses the libcephfs (and librados) to consume the cluster.
> > It's not re-exporting a mounted Ceph filesystem.
> >
> > Matt
> >
> > - "Timofey Titovets"  wrote:
> >
> >> showmount -e 172.20.252.12
> >> Export list for 172.20.252.12:
> >> / (everyone)
> >>
> >> 2015-04-24 10:33 GMT+03:00 DENIEL Philippe :
> >> > Hi,
> >> >
> >> > what does " showmount -e 172.20.252.12 " say ? This way, you'll see
> >> if
> >> > Ganesha was capable of building the export entries.
> >> > My knowledge of CEPH is weak, so I forward your question to
> >> > nfs-gamesha-devel. In particular, I do not know if:
> >> >  - CEPH support open_by_handle_at() syscall
> >> >  - FSAL_CEPH can work on a "regular" CEPH distribution. I
> >> remember
> >> > that Matt and Adam made some changes to CEPH to ease pNFS
> >> > implementation, and I do not know if those commits went upstream.
> >> They
> >> > will tell us about this.
> >> >
> >> >  Regards
> >> >
> >> >  Philippe
> >> >
> >> > On 04/24/15 09:18, Timofey Titovets wrote:
> >> >> Good time of day, I've try to setup nfs-ganesha server on Ubuntu
> >> 15.04
> >> >> Builded by last source from master tree.
> >> >>
> >> >> 1. Can't be mounted with nfsv3
> >> >> Config:
> >> >> EXPORT
> >> >> {
> >> >>  # Export Id (mandatory, each EXPORT must have a unique
> >> Export_Id)
> >> >>  Export_Id = 77;
> >> >>  # Exported path (mandatory)
> >> >>  Path = /storage;
> >> >>  # Pseudo Path (required for NFS v4)
> >> >>  Pseudo = /cephfs;
> >> >>  Access_Type = RW;
> >> >>  NFS_Protocols = 3;
> >> >>  FSAL {
> >> >>  Name = VFS;
> >> >>  }
> >> >> }
> >> >> Or
> >> >> EXPORT
> >> >> {
> >> >> Export_ID = 1;
> >> >> Path = "/";
> >> >> Pseudo = "/cephfs";
> >> >> Access_Type = RW;
> >> >> NFS_Protocols = 3;
> >> >> Transport_Protocols = TCP;
> >> >> FSAL {
> >> >> Name = CEPH;
> >> >> }
> >> >> }
> >> >>
> >> >> On client I've get:
> >> >> # mount -o nfsvers=3 172.20.252.12:/ /mnt -v
> >> >> mount.nfs: timeout set for Fri Apr 24 09:47:50 2015
> >> >> mount.nfs: trying text-based options
> >> 'nfsvers=3,addr=172.20.252.12'
> >> >> mount.nfs: prog 13, trying vers=3, prot=6
> >> >> mount.nfs: trying 172.20.252.12 prog 13 vers 3 prot TCP port
> >> 2049
> >> >> mount.nfs: prog 15, trying vers=3, prot=17
> >> >> mount.nfs: trying 172.20.252.12 prog 15 vers 3 prot UDP port
> >> 40321
> >> >> mount.nfs: mount(2): Permission denied
> >> >> mount.nfs: access denied by server while mounting 172.20.252.12:/
> >> >>
> >> >> What's did I wrong? %)
> >> >>
> >> >
> >> >
> >> >
> >> -
> >> -
> >> > One dashboard for servers and applications across
> >> Physical-Virtual-Cloud
> >> > Widest out-of-the-box monitoring support with 50+ applications
> >> > Performance metrics, stats and reports that give you Actionable
> >> Insights
> >> > Deep dive visibility with transaction tracing using APM Insight.
> >> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >> > ___
> >> > Nfs-ganesha-support mailing list
> >> > nfs-ganesha-supp...@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-support
> >>
> >>
> >>
> >> --
> >> Have a nice day,
> >> Timofey.
> >>
> >> -
> >> - One dashboard for servers and applications across
> >> Physical-Virtual-Cloud Widest out-of-the-box monitoring support with
> >> 50+ applications Performance metrics, stats and reports that give you
> >> Actionable Insights Deep dive visibility with transaction tracing
> >> using APM Insight.
> >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >> ___
> >> Nfs-ganesha-devel mailing list
> >> Nfs-ganesha-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >
> > --
> > Matt Benjam

[Nfs-ganesha-devel] PLEASE READ - Merge nightmare - may not be a dev-1 this week

[Frank Filz]

Ok, using gerrithub is really feeling like it's not going to work for me...

Merging a patch set with multiple patches is impossible to manage. There's
no assistance in keeping track of the order of merging patches.

At this moment, my gerrithub next branch is partially merged. This MUST NOT
BE RELIED ON - PLEASE DO NOT REBASE - HISTORY WILL BE CHANGING

I'm not sure how to proceed, there probably won't be a dev-1 this week.

I'm ready to go back to github and skip gerrithub.

Either that or we abandon the incremental patch idea and each feature is ONE
patch. Heaven help us to try and review those...

Frank



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] [Nfs-ganesha-support] Troubles with configuration

[Frank Filz]

Using a Path of "/" shouldn't be the problem. Also, that doesn't explain why
the FSAL_VFS export isn't working either.

Frank

> -Original Message-
> From: Soumya Koduri [mailto:skod...@redhat.com]
> Sent: Friday, April 24, 2015 11:18 AM
> To: Timofey Titovets; philippe.den...@cea.fr
> Cc: nfs-ganesha-supp...@lists.sourceforge.net; nfs-ganesha-
> de...@lists.sourceforge.net
> Subject: Re: [Nfs-ganesha-devel] [Nfs-ganesha-support] Troubles with
> configuration
> 
>  >>> # mount -o nfsvers=3 172.20.252.12:/ /mnt -v
> 
> Looks like you are trying to mount "/" via v3. "/" is reserved for psuedo
file
> system which can be mounted only via "v4" AFAIK.
> 
> Please try using a different path other than '/' in your Export Block.
> 
> 
>  >>> EXPORT
>  >>> {
>  >>>   # Export Id (mandatory, each EXPORT must have a unique
> Export_Id)
>  >>>   Export_Id = 77;
>  >>>   # Exported path (mandatory)
>  >>>   Path = /storage;
>  >>>   # Pseudo Path (required for NFS v4)
>  >>>   Pseudo = /cephfs;
>  >>>   Access_Type = RW;
>  >>>   NFS_Protocols = 3;
>  >>>   FSAL {
>  >>>   Name = VFS;
>  >>>   }
>  >>> }
> In this case, the path exported is
> "/storage" for v3 and
> "/cephfs" for v4
> 
>  >>> Or
>  >>> EXPORT
>  >>> {
>  >>>  Export_ID = 1;
>  >>>  Path = "/";
>  >>>  Pseudo = "/cephfs";
>  >>>  Access_Type = RW;
>  >>>  NFS_Protocols = 3;
>  >>>  Transport_Protocols = TCP;
>  >>>  FSAL {
>  >>>  Name = CEPH;
>  >>>  }
>  >>> }
> As I said, '/' is reserved, you may need to use different Path here.
> 
> Thanks,
> Soumya
> 
> On 04/24/2015 02:14 PM, Timofey Titovets wrote:
> > showmount -e 172.20.252.12
> > Export list for 172.20.252.12:
> > / (everyone)
> >
> > 2015-04-24 10:33 GMT+03:00 DENIEL Philippe :
> >> Hi,
> >>
> >> what does " showmount -e 172.20.252.12 " say ? This way, you'll see
> >> if Ganesha was capable of building the export entries.
> >> My knowledge of CEPH is weak, so I forward your question to
> >> nfs-gamesha-devel. In particular, I do not know if:
> >>   - CEPH support open_by_handle_at() syscall
> >>   - FSAL_CEPH can work on a "regular" CEPH distribution. I
> >> remember that Matt and Adam made some changes to CEPH to ease
> pNFS
> >> implementation, and I do not know if those commits went upstream.
> >> They will tell us about this.
> >>
> >>   Regards
> >>
> >>   Philippe
> >>
> >> On 04/24/15 09:18, Timofey Titovets wrote:
> >>> Good time of day, I've try to setup nfs-ganesha server on Ubuntu
> >>> 15.04 Builded by last source from master tree.
> >>>
> >>> 1. Can't be mounted with nfsv3
> >>> Config:
> >>> EXPORT
> >>> {
> >>>   # Export Id (mandatory, each EXPORT must have a unique
> Export_Id)
> >>>   Export_Id = 77;
> >>>   # Exported path (mandatory)
> >>>   Path = /storage;
> >>>   # Pseudo Path (required for NFS v4)
> >>>   Pseudo = /cephfs;
> >>>   Access_Type = RW;
> >>>   NFS_Protocols = 3;
> >>>   FSAL {
> >>>   Name = VFS;
> >>>   }
> >>> }
> >>> Or
> >>> EXPORT
> >>> {
> >>>  Export_ID = 1;
> >>>  Path = "/";
> >>>  Pseudo = "/cephfs";
> >>>  Access_Type = RW;
> >>>  NFS_Protocols = 3;
> >>>  Transport_Protocols = TCP;
> >>>  FSAL {
> >>>  Name = CEPH;
> >>>  }
> >>> }
> >>>
> >>> On client I've get:
> >>> # mount -o nfsvers=3 172.20.252.12:/ /mnt -v
> >>> mount.nfs: timeout set for Fri Apr 24 09:47:50 2015
> >>> mount.nfs: trying text-based options 'nfsvers=3,addr=172.20.252.12'
> >>> mount.nfs: prog 13, trying vers=3, prot=6
> >>> mount.nfs: trying 172.20.252.12 prog 13 vers 3 prot TCP port
> >>> 2049
> >>> mount.nfs: prog 15, trying vers=3, prot=17
> >>> mount.nfs: trying 172.20.252.12 prog 15 vers 3 prot UDP port
> >>> 40321
> >>> mount.nfs: mount(2): Permission denied
> >>> mount.nfs: access denied by server while mounting 172.20.252.12:/
> >>>
> >>> What's did I wrong? %)
> >>>
> >>
> >>
> >> -
> >> - One dashboard for servers and applications across
> >> Physical-Virtual-Cloud Widest out-of-the-box monitoring support with
> >> 50+ applications Performance metrics, stats and reports that give you
> >> Actionable Insights Deep dive visibility with transaction tracing
> >> using APM Insight.
> >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >> ___
> >> Nfs-ganesha-support mailing list
> >> nfs-ganesha-supp...@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-support
> >
> >
> >
> 
>

--
> One dashboard for servers and applications across Physical-Virtu

[Nfs-ganesha-devel] DISCUSSION: V2.3 workflow and how we proceed

[Frank Filz]

So I tried to merge using gerrithub today. The procedure I had intended to
follow will not be sustainable as just an extension of the workflow we have
used in the past.

As a result of this, I did some merges with gerrithub, and then have
force-updated the branch to revert it to V2.3-dev-0 (Sorry Bill, I really
didn't want to have to do that after just messing you up...). There will not
be a V2.3-dev-1 this week.

At this point, I see a variety of options for proceeding:

0. Suck it up. Release manager may go insane the first time he has to merge
a submission with 20 or 30 or more patches.

1. Abandon gerrithub, revert to using github branches for review and merge.
This has a few problems. The biggest is that review history is hard to find
when a patch is updated for any reason. Other problems in the past were
folks using github pull requests (which are trickier to find the right thing
to pull into my local git repo) and posting just the patch SHA1, leaving me
to have to scrounge through their branches to find the branch that has the
patch(es). Also, folks don't tend to clean up their old branches so pulling
in someone's remote can pull down a huge number of branches (which can
mostly be ignored - except when they use a new branch when they update the
patch).

2. Abandon gerrithub, but find some other way to do code review where we
don't lose accessibility to review comments when folks update their patches.

2a. One solution here is use an e-mail review system (like the kernel
process). This could be e-mail exclusively (I would then have to set up
e-mail on my Linux VM in order to be able to merge patches via e-mail). I'm
not fond of this process, but it would be workable.

3. Change our workflow to work with gerrithub better (stop using the
incremental patch process). One loss here would be the ability to bisect and
hone in on a small set of changes that caused a bug.

3a. The most extreme option would be to abandon incremental patches. If you
have a body of work for submission in a given week, you submit one patch for
that work. This is not appealing from a code review standpoint. It might not
be so bad as in the past since we hopefully won't have major style re-writes
that make it impossible to review changes when combined with functional
changes, we still do see some interface changes that require many trivial
changes. When these are combined in the same patch as a significant
functional change, it can still be hard to find the functional change and
properly review it.

3b. A less extreme possibility would be to encourage folks to package
submissions tighter. Keep style changes to a separate patch. Keep those
massive interface modifications to a separate path. Combine ALL the
functionality of a new patch into one patch (or if it really is too big,
maybe two or three patches). Make sure the patch titles make it clear what
sequence they should be applied (like "Stage interface changes for Feature
A", "Implement Feature A", "Enhance debugability and documentation for
Feature A").

3c. A process implied by a post Matt found: Perform code review with
incremental patches. Once submission is ready, squash the submission into a
single patch and get final signoffs on that. Then the single patch is
merged.

If we proceed with gerrit, Malahal and Vincent will need to re-submit their
patches with new changeids (Vincent technically need only introduce new
changeids for the two patches I merged). Sorry - there is no way I can
re-open those changeids.

Some additional thoughts no matter what we do:

1. We need more participation in review and verification on a timely basis.

2. We should make sure each patch that has significant impact in areas the
author may not be able to test is verified by someone who is able to test
that area, and then make sure we document that verification in the review
history (here is where gerrit COULD shine).

3. It would be helpful to be able to identify one or two critical reviewers
for each patch, and then make sure those people are able to review the
patch. For those patches that may need more than a couple people to review,
we need to stage them at least a week ahead of when we expect them to be
merged, and then somehow flag those patches as high priority for all
required reviewers to actually review.

Thanks

Frank




--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] More thoughts on the merge process/gerrit

[Frank Filz]

I had some insight yesterday.

>From my perspective as release manager, there are four major aspects to code
submissions to an open source project:

Review: Having other eyes look at your code (and even test it) with the goal
of tuning the submission to be the best possible.

Acks and Acked-by: The final stage of the review process where folks add a
vote of confidence to submissions. It is helpful for these to be recorded to
increase the pool of people who might be asked in the future "why did this
code submission get written this way?".

Staging: This is the process of collecting submissions in preparation for
merge. It allows the release manager and others to get a feeling for what is
coming, and do some testing of the aggregate. It also offers the possibility
of tracking what has been collected so far. Staging should allow posting of
temporary branches that do not commit to that version of the code history
(i.e. force pushes are acceptable) so everyone can play with a proposed
merge of a group of submissions.

Merge and Tag: The process of finalizing a bunch of submissions. The tag
indicates a point that is suitable for forking temporary development
branches, and for submission to more formal testing by QA departments.
Anyone can check the code base and know what V2.3-dev-1 means (as opposed to
"Tuesday's build").

Now with those four stages, this is how I see gerrithub fitting in:

Review: gerrithub is really good for this. The idea of changeids allows
comments over a series of patch updates to easily be found. The GUI tool
makes it easy to see the comments in relationship to the code and provides
notification to everyone. It allows anyone to see the entire history of
review comments (e-mails can get dumped in the trash etc.). I also like the
idea of the -2, -1, 0, +1, and +2 votes. Also the idea that review and
verification are separate and both important, we need more verification (and
I appreciate those who DO seek verification and do verification).

Acked-by: gerrithub really doesn't help with this with our current model of
lots of concurrent development and incremental patches.

Staging: gerrithub does make it easier to see the patches currently
available for consideration, however, it does not help with creating a
temporary merge of multiple submissions and tracking what has been
experimented with. The only tracking it provides is during the final merge.

Merge and Tag: gerrithub is not useful to us for this.

The big issue I feel is that gerrit is designed for a workflow where really
only one patch set is under consideration at a time. There COULD be multiple
submissions, but ultimately, they will be taken one at a time, serially.
Ideally a patch set is a single commit, though it makes some attempt to
support a patch set that has several commits.

Based on this, if we can not come up with a better solution for code review,
I would be happy to continue using gerrithub for code review. On the other
hand, I really want to explore a different mechanism for acks, staging, and
merge/tag, with the big focus on a different mechanism for staging.

Thanks

Frank


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] DISCUSSION: V2.3 workflow and how we proceed

[Frank Filz]

> reply is in the message body. I cut some pieces of your original message
to
> avoid a too long message where information would be diluted.
> 
> On 04/24/15 23:59, Frank Filz wrote:
> > 1. Abandon gerrithub, revert to using github branches for review and
> merge.
> > This has a few problems.
> The issue with github-based reviews are known. Avoiding solving a current
> issue by stepping back to formerly known problems may seem comfortable,
> but this is no evolution, it's clearly a regression.
> 
> > 2a. One solution here is use an e-mail review system (like the kernel
> > process).
> This is prehistory... Kernel community works like this because they have
this
> habit since the (Linux) world was new and nothing else existed. Can
> someone seriously say it would be user-friendly ? OK, mail are archived,
but
> not indexed. Looking for a review will be like lookingfora needle ina
haystack.
> Once hundreds of mail will have been sent and received and re-re-re-re-
> replied finding useful information will become impossible.
> Please don't bring us back to Stone Age.

I was only offering these (github and e-mail) in the spirit of offering
everything :-) And actually to encourage actual discussion of what we really
need and how to accomplish that.

> > 3. Change our workflow to work with gerrithub better (stop using the
> > incremental patch process). One loss here would be the ability to
> > bisect and hone in on a small set of changes that caused a bug.
> It seems like a much better idea. People in my team are developing in the
> Lustre code. The Lustre community works with a private gerrit since the
> beginning. They have their best practices and their workflow.
> In particular, they have "Patch windows" : when the window is opened,
> people can submit patchsets. As it closed, people review it, fix stuff,
rebase
> code, and the branch is released. No new patchset comes at this time. Then
> the window opens again and a new cycle starts. One important point : the
> "master repo" is the git inside gerrit and no other. This means that
> contributors would only fetch gerrithub to rebase their work, github will
then
> become a simple mirror.
> Clearly, the "merge/fix/rebase" process is longer than a week. We could
> work this way by simply abandon the one-week cycle we are accustomed to.
> It's just a matter of using new, more adapted, rules and best practises.
> 
> > 3a. The most extreme option would be to abandon incremental patches.
> > If you have a body of work for submission in a given week, you submit
> > one patch for that work.
> Again, I believe that the one-week cycle is the real issue and it's such a
> constraint for release management. You should open/close the submission
> window at your will. It would ease your work a lot, wouldn't it ? Remember
> that gerrit was designed to help the release manager, it's not designed to
be
> that painful. We may just use the tool the wrong way.

The problem with a longer that one  week cycle is that we get larger and
larger volumes of patches. With the right tools, we can sustain a weekly
cycle.

Note however that the review cycle of a patch set needs to be understood to
not always be a week. Sometimes it will take several weeks of iterations.

What I want to work on though is responsiveness when people submit patches
that they get a first review in a timely fashion.

Also, with the changeid allowing review comments to be tracked across
versions of a patch, I want to encourage posting patches for review earlier
so the major features are getting reviewed as they are developed, not one
huge review at the end that no one can keep track of.

> > 3c. A process implied by a post Matt found: Perform code review with
> > incremental patches. Once submission is ready, squash the submission
> > into a single patch and get final signoffs on that. Then the single
> > patch is merged.
> People can rebase their patchset, even when submitted to gerrit and I
think
> they should keep the same changeid. Remember that changeid is nothing
> but a mark on a commit to allow gerrit to keep patchset history.
> It's not a commit id.
> 
> >
> > If we proceed with gerrit, Malahal and Vincent will need to re-submit
their
> > patches with new changeids
>  From my point of view, changing the changeids would clearly be a misuse
> of gerrit.

We have to do it because once a changeid has been merged, it is marked
closed, and can't be resubmitted. This happened because the way we are
trying to use gerrithub is non-native and I messed up. This will never
happen again (with the usual caveat, never say never).

> > 1. We need more participation in review and verification on a timely
basis.
> Yes. Bu

Re: [Nfs-ganesha-devel] DISCUSSION: V2.3 workflow and how we proceed

[Frank Filz]

> > >> From what I can tell, Frank finds problematic
> > >
> > > 1) a lack in gerrit of a "changeset" concept, plus, apparently
> >
> > It actually exists and is called “topic”. It will be very soon
> > possible as well to merge a whole topic atomically with one click.
> 
> I found "topic" mentioned in some online discussion, but there seemed to be
> mixed reviews from some developers.  I didn't come away with a clear sense
> of the strengths and weaknesses of the feature, but there appear to be
> tradeoffs.

Being able to merge a whole topic with one click will really help us.

> > It is actually in beta and will be released very soon: it is called
> > “NoteDB”. It is basically the archive of all review history (including
> > ratings and comments) as Git objects.
> 
> This sounds interesting, but what I think Frank and Dominique were
> specifically looking for is for the affirmative reviews in gerrit to be
> transformed into "Acked-By" statements in the primary commit msg in git on
> merge.
> 
> Is that behavior part of NoteDB, or, alternately, something that we can
> straightforwardly accomplish with gerrithub?

With the gerrithub cherry pick merge form, we get reviewed-by and tested-by 
added to the patch.

Apparently we could also add an Acked-by label. I will have a look at that, 
though I'd be happy with the reviewed-by and tested-by annotations in the 
commit message. In fact, adding an acked-by might add additional churn to the 
review process.

Frank


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] DISCUSSION: V2.3 workflow and how we proceed

[Frank Filz]

> Dear Matt,
> please see below some additional background on Gerrit that you might find
> useful.
> 
> > On 28 Apr 2015, at 16:09, Matt W. Benjamin  wrote:
> >
> > Hi,
> >
> > As I mentioned in an IRC discussion, my recollection from when OpenAFS
> > implemented gerrit (also their own installation, but not to my
> > knowledge customized), it was basically mandated that developers
> > submit "one patch per change."
> >
> >> From what I can tell, Frank finds problematic
> >
> > 1) a lack in gerrit of a "changeset" concept, plus, apparently
> 
> It actually exists and is called “topic”. It will be very soon possible as 
> well to
> merge a whole topic atomically with one click.

Looking at this, this may well be our solution. I have some questions:

1. Will it let you one click merge with the "cherry pick" merge style? If so, 
that will be awesome, one click and I get all the review and verify signoffs 
into the commit messages.

2. In a subsequent e-mail, I think you were offering us a staging version of 
gerrithub? If so, is the topic stuff stable enough that we could play with it?

In the meantime, I see enough potential here, and I see that gerrithub review 
process has enough positives to it that I feel like we can use it for review, 
and I can do merges by pulling patch sets from gerrithub (apparently git-review 
can do this, or it's not too hard to do with the "download" options from 
gerrithub).

Frank

> > 2) some missing automation to propagate review information into
> >   git's history/commit msg
> 
> It is actually in beta and will be released very soon: it is called “NoteDB”. 
> It is
> basically the archive of all review history (including ratings and comments) 
> as
> Git objects.
> 
> >
> > I think both are potentially legitimate considerations, with a claim
> > to be related to best practices (so potentially on a par with the
> > motivations to update the review process).
> >
> > In large corporate development environments I've worked in, the
> > aspiration to get the 20% lacking in the off-the-shelf tool would be
> > solved by some internal development.  In other cases, someone said,
> > "no discussion, we're using VSS."
> >
> > I don't have a very strong opinion, but I do somewhat feel that
> > however much gerrit helps with some review beset practices, just doing
> > what gerrithub appears to support oob probably brings arbitrary
> > processes, not just best practices.
> >
> > At the same time, I think the objection to "one patch per change"
> > (which appears to be, "this well-formed, logical change which touches
> > many files is too big for me t review") may be overblown.
> >
> > If we could do one patch per-change, objection #1 might be overcome.
> > To overcome objection #2 seems to require some minimal tooling--I'm
> > unclear whether it is compatible with gerrithub; If for some reason
> > not, is there an organization volunteering to host and
> > maintain/co-maintain aprivate gerrit installation?
> >
> > Matt
> >
> > - "DENIEL Philippe"  wrote:
> >
> >> Hi Frank,
> >>
> >> reply is in the message body. I cut some pieces of your original
> >> message to avoid a too long message where information would be
> >> diluted.
> >>
> >> On 04/24/15 23:59, Frank Filz wrote:
> >>> 1. Abandon gerrithub, revert to using github branches for review and
> >> merge.
> >>> This has a few problems.
> >> The issue with github-based reviews are known. Avoiding solving a
> >> current issue by stepping back to formerly known problems may seem
> >> comfortable, but this is no evolution, it's clearly a regression.
> >>
> >>> 2a. One solution here is use an e-mail review system (like the
> >> kernel
> >>> process).
> >> This is prehistory... Kernel community works like this because they
> >> have this habit since the (Linux) world was new and nothing else
> >> existed.
> >> Can
> >> someone seriously say it would be user-friendly ? OK, mail are
> >> archived, but not indexed. Looking for a review will be like
> >> lookingfora needle
> >>
> >> ina haystack. Once hundreds of mail will have been sent and received
> >> and re-re-re-re-replied finding useful information will become
> >> impossible.
> >>
> >> Please don't bring us back to Stone Age.
> >>
> >>> 3. Change our workflow to wor

Re: [Nfs-ganesha-devel] DISCUSSION: V2.3 workflow and how we proceed

[Frank Filz]

> From: Malahal Naineni [mailto:mala...@us.ibm.com]
> DENIEL Philippe [philippe.den...@cea.fr] wrote:
> > issue. If I do a big patch or 10 small ones, all of my changed files
> > will have to be reviewed, which does have no impact on the workload.
> > In fact, one big patch is a cool situation : it is easy to rebase, and
> > it depends only on stuff already pushed and landed. If I publish 5
> > patches, what if patch 1, 2 and 3 merge fine, but 4 produce a conflict
> > ? How could I rebase 4 without touch 1,2 and 3 ? This leads to a
> > dependencies maze, and this is precisely the situation we fell into.
> 
> There is no doubt that a "well" split patchset is easier to review. I did
rebase
> mega patches from others (that happens when you pick up someone else's
> work) in the past and it is a PITA. Even if it is my code, I find it lot
easier to
> rebase small patches than one big patch.

> From: Dominique Martinet [mailto:dominique.marti...@cea.fr]
> >  - we should provide big and squashed patches, one per feature.
> > For example, CEA will soon push a rework of FSAL_HPSS, this will be a
> > single commit.
> 
> We do that for HPSS because the FSAL is old, has been pruned out a while
> ago, and currently doesn't checkpatch/individual patches won't checkpatch.
> That's purely selfish and we don't actually expect anyone to review that
code
> anyway, since no-one in the active community will use it - it's pretty far
from
> normal workflow submitting...
> 
> 
> I believe patches should be kept reasonably small for review, really, but
> "reasonably small" is subjective and flexible.
> what we really need is for more people to review and that's not going to
> improve if we push big hunks :)

I absolutely agree. Maybe we don't need to have the patch granularity as
fine as Linux kernel, but I like to see smaller patches. They also make for
more bisectable code since we can see "ok, this part of the feature caused
the problem" rather than "hmm, there's a  problem somewhere in this new huge
feature."

Frank



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] DISCUSSION: V2.3 workflow and how we proceed

[Frank Filz]

> There clearly are people who think reviewing something large in small chunks
> is categorically easier, but, I don't completely understand the reasoning.
> 
> 1) It seems to me that whether the small chunks are easier to actually
> understand, depends on whether the chunks can really be understood in
> isolation.  Sometimes, that's not really the case.  It's well known from Linux
> kernel development that not infrequently, splitting a logical change actually
> makes review and intake more difficult, producing extra workload on
> submitters who are asked to make chunks build separately, bisectable, etc.
> 
> 2) When a set of chunks could have been understood in isolation, then a
> competent reviewer can probably look at sets of related, changed files
> (navigating to them in the review tool), with the added benefit that the
> reviewer can jump to any other part of the logical change to compare
> context.

I agree in part with you, and I do think the kernel community sometimes takes 
granularity too far. Of course in a land of e-mail patch review, clearly too 
large a patch is impossible to review in e-mail.

I think there's a balance. I know I'm still working to find that balance for 
myself.

There are times when a single huge patch is certainly appropriate (new FSAL is 
a great one).

I also like the "introduce a new function in one patch, and then modify places 
to call it in another patch, or even multiple patches if there's a lot of 
changes".

One nice thing about the multiple patches for multiple changes across a wide 
space is for example, say I'm making a major FSAL API change. If each FSAL can 
be changed in a separate patch, then when FSAL_GPFS is Acked by Marc, I know 
that piece is done. If all the FSALs are in one patch, when Marc Acks, that 
doesn't tell me anything about the acceptability of the change as a whole (and 
we don't easily know whose Ack is missing - though that would be solved by 
having a required reviewers list).

What I would ask people to do is be considerate of the reviewers. Break up 
large features into sensible patches. Avoid combining small changes unless they 
are trivial (I don't need to see 20 patches because you found 20 one or two 
line bugs while running some test suite - go ahead and give me one patch for 
those).

Note also that with git-review or other mechanism of pulling the patches into a 
local repo, it is then possible to review the patch set as a single diff (and I 
actually do that sometimes, though actually what I look at is the final result).

Frank



> - "Frank Filz"  wrote:
> 
> > > From: Malahal Naineni [mailto:mala...@us.ibm.com] DENIEL Philippe
> > > [philippe.den...@cea.fr] wrote:
> > > > issue. If I do a big patch or 10 small ones, all of my changed
> > files
> > > > will have to be reviewed, which does have no impact on the
> > workload.
> > > > In fact, one big patch is a cool situation : it is easy to rebase,
> > and
> > > > it depends only on stuff already pushed and landed. If I publish
> > 5
> > > > patches, what if patch 1, 2 and 3 merge fine, but 4 produce a
> > conflict
> > > > ? How could I rebase 4 without touch 1,2 and 3 ? This leads to a
> > > > dependencies maze, and this is precisely the situation we fell
> > into.
> > >
> > > There is no doubt that a "well" split patchset is easier to review.
> > I did
> > rebase
> > > mega patches from others (that happens when you pick up someone
> > else's
> > > work) in the past and it is a PITA. Even if it is my code, I find it
> > lot
> > easier to
> > > rebase small patches than one big patch.
> >
> > > From: Dominique Martinet [mailto:dominique.marti...@cea.fr]
> > > >  - we should provide big and squashed patches, one per
> > feature.
> > > > For example, CEA will soon push a rework of FSAL_HPSS, this will
> > be a
> > > > single commit.
> > >
> > > We do that for HPSS because the FSAL is old, has been pruned out a
> > while
> > > ago, and currently doesn't checkpatch/individual patches won't
> > checkpatch.
> > > That's purely selfish and we don't actually expect anyone to review
> > that
> > code
> > > anyway, since no-one in the active community will use it - it's
> > pretty far
> > from
> > > normal workflow submitting...
> > >
> > >
> > > I believe patches should be kept reasonably small for review,
> > really, but
> > > "reasonably small" is subjective and flexible.
> > > what we really nee

Re: [Nfs-ganesha-devel] DISCUSSION: V2.3 workflow and how we proceed

[Frank Filz]

> On 04/28/15 18:13, Frank Filz wrote:
> (...)
> > The problem with a longer that one  week cycle is that we get larger
> > and larger volumes of patches. With the right tools, we can sustain a
> > weekly cycle.
> We introduced the 1-week cycle to regulate/sort patches, for we had no
> other way of doing it when using github.
> I think that gerrit can help regulating patches workflow and so removes
the
> need for a 1-week cycle.
> What we should do could look like this:
>  - people depose patches and asks people to review it
>  - gerrit runs automated test on it (like checkpatch) and verify the
patches
>  - do add +1/-1... new version of the patch is done, discussion are
made...
> and finally the patch is ready
>  - at this point, people contact the release manager (aka Frank ;-)
> ) and ask for landing the patch.
>  - if the patch is mergeable (fast-forwardable) it is merged
(cherry-pick
> button in github interface), if not, owner will have to rebase it and
restart the
> whole review process This can be done on the fly, as patches arrive and
are
> reviewed. This change a constrained 1-week cycle against several, less
> constrained, cycles, one per patch. Keeping this in mind, a single "big
and
> squashed"
> patch is clearly easier to manage. As Matt said, bigger patches are no
issue. If
> I do a big patch or 10 small ones, all of my changed files will have to be
> reviewed, which does have no impact on the workload. In fact, one big
patch
> is a cool situation : it is easy to rebase, and it depends only on stuff
already
> pushed and landed. If I publish 5 patches, what if patch 1, 2 and 3 merge
fine,
> but 4 produce a conflict ? How could I rebase 4 without touch 1,2 and 3 ?
This
> leads to a dependencies maze, and this is precisely the situation we fell
into.

I'm not going to do a rolling merge on a regular basis. Also, the problem
with this is that if a bunch of patches are submitted at once, one of them
goes in, and then everyone else has to re-submit their patches. And then the
next one goes in, and then some more people have to rebase their patches
AGAIN. The poor guy at the end of the line has spent his week rebasing his
patch... Rolling merge also asks me for more interruption of my workflow to
do the merges. Plus, until we have a good automated test, I will have to
manually run tests on every patch. When we have a good comprehensive
automated test suite, we can talk about relieving the release manager of
that responsibility.

> Regarding, I believe we should:
>   - nfs-ganesha in gerrithub (Frank's home in gerrithub) should accept
only
> fast-forwardable commit (that's a matter of clicking on the right button
in the
> right page)
>  - we should provide big and squashed patches, one per feature. For
> example, CEA will soon push a rework of FSAL_HPSS, this will be a single
> commit.
>  - the git in gerrit is the reference. Forget githib, at best it a
clone to expose
> code in a fancy way. This mean that we stop fetch frank's github and we
> fetch frank's gerrithub. This is a very important point. It seems to me
that if a
> patch is landed in gerrithub, the related github repository is
automatically
> updated. This will prevent Frank from doing not-funny work, getting things
> on one side to push it on the other. We use gerrit, gerrit becomes our
> reference. That's as simple as that. Forget github or use it to store
work-in-
> progress stuff of your own.

Github is here to stay. This branch:

https://github.com/nfs-ganesha/nfs-ganesha/commits/next

Will always be the "official" current state of the development branch. I
will ALSO push the same to gerrithub, but the nfs-ganesha github is the
branch people should look to for tagged weekly merges. And of course:

https://github.com/nfs-ganesha/nfs-ganesha/commits/master

Is the official current stable release (with additional branches for stable
bugfixes).

> > Note however that the review cycle of a patch set needs to be
> > understood to not always be a week. Sometimes it will take several weeks
> of iterations.
> As I said, the "one single 1-week cycle" is replaced by "several
independent
> patch-related cycle". Some may take weeks, some may take days or less. The
> 1-week cycle is github related. If we stop using github as a reference and
use
> gerrithub instead, we have no need for this 1-week constraint.
> 
> > What I want to work on though is responsiveness when people submit
> > patches that they get a first review in a timely fashion.
> They can. People could then add stuff in the patch, and squash the result
in a
> new patch. If the ChangeId is preserved, gerrit will understand that this
is a
> new version of an already known patchset and keep the s

[Nfs-ganesha-devel] Announce Push of V2.3-dev-1

[Frank Filz]

Branch next

Tag:V2.3-dev-1

NOTE: Since we will eventually be using gerrithub cherrypick merge, I have
opted to rebase branches rather than merge. This will simplify history (and
actually improve bisectability).

Highlights

* Removed NSM_Use_Caller_Name from the gpfs config file.

* Release_IP should not remove the clientid record which will be read by
  the takeover node.

* Fix up FSAL_NULL

Signed-off-by: Frank S. Filz 

Contents:

6f08a01 Frank S. Filz V2.3-dev-1
ba17669 Poornima Gupte Removed NSM_Use_Caller_Name from the gpfs config
file.
fa4cbbb lancerus Release_IP should not remove the clientid record which will
be read by the takeover node.
a162c25 Vincent Saulue-Laborde Nullfs : updating read_dirents to use nullfs
handles.
60a2707 Vincent Saulue-Laborde Nullfs : adding a callback function for
read_dirents
8451a25 Vincent Saulue-Laborde Nullfs : updating functions
allocating/releasing handles
fa5c812 Vincent Saulue-Laborde Nullfs : added functions to allocate and init
handles.
3dd7615 Vincent Saulue-Laborde Nullfs : rewriting simple fsal functions
using new handle
6f137e2 Vincent Saulue-Laborde Nullfs : adding a function to copy attributes
of handles
09af40c Vincent Saulue-Laborde Nullfs : nullfs_fsal_obj_handle type
modification.


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] V2.3 workflow - final (for now) version

[Frank Filz]

After much discussion, experimentation, and wrangling, here is the scoop:

We will use gerrithub for code review and submission. I will expect every
patch to get a +1 review from at least one other person. If the patch
touches certain touchy areas, or other people's FSALs, I will add additional
reviewers and look for +1 from each of those reviewers as much as possible.
I ask everyone to participate in review. E-mails will be sent to the mailing
list when patches are submitted. Also you can check this page:

https://review.gerrithub.io/#/q/status:open+project:ffilz/nfs-ganesha+branch
:next

I still prefer to see incremental patches rather than monolithic patches,
however, rather than following absolute rules, let's be reasonable. If your
feature is small, feel free to submit as a single patch. If your feature is
large and can be broken down into sensible incremental chunks, please do so.
If you are making a significant API change (function prototypes and/or
structures) to support some new feature, I would prefer to see that change
in its own patch along with changing all existing callers as necessary. Then
in a separate patch (or patches), introduce your new calls and code segments
to enable the new feature. Absolutely, if you feel a need to do cosmetic
changes that are not small and local to the changes you are making, please
do so in a separate patch. Such patches are easy to do a skim review of.
While we have a lot of consistency of coding style, the auto-indent process
made a mess of some code and someone may still take a dislike to instances
of pfoo. Changes in these areas are welcome, but please, in a separate
patch.

All patches must pass checkpatch.pl OR have an explanation as to why not.
Thanks to Dominique, we have checkpatch.pl run on every patch submitted to
gerrithub. This will actually allow folks to review any failures and discuss
possible fixes or if an exception is warranted. With this, there will not be
any surprises. Exceptions are quickly granted for minor changes in code that
was previously exempt and cases where checkpatch.pl gets confused by the
changes,(removing and adding lines sometimes confuses checkpatch's brace
checking - however, in this case:

If (test) {
function_call_1();
function_call_2();
}

If you delete function_call_2() please also delete the braces OR add a
comment if you strongly feel the braces should remain.

I will still be building weekly. The earlier in the week you submit your
patch to gerrithub, the more likely it will make that week's merge.

On Thursday (as much as possible), I will look for patches that have met the
reviewing standards and start staging them into the weekly merge. I may post
this merge to my fffilz github in the stage branch. I will be rebasing
branches rather than merging. If I run into troubles with merge, compile, or
testing, I will post comments on  gerrithub that day. This will give people
until Friday to fix things and still make the weekly merge. If you are
racing to try and fix something, I will consider taking patches as late as
Friday noon Pacific time. Of course such late patches may not get a second
chance if problems arise (being available on IRC helps though...).

Once the staging branch passes my testing, I will update CMakeLists.txt and
add a signed tag. This then will be pushed to nfs-ganesha next, ffilz next,
and gerrithub next. The push to gerrithub will then mark all the patches as
closed. In the future, the final merge will actually be done inside
gerrithub.

With all of this, github will not much be used by individual contributors.
You may still desire to push branches there for FYI, on the other hand,
there's not much harm in pushing to gerrithub. It's also easy to pull down
someone's branch from gerrithub.

Take this change for example:

https://review.gerrithub.io/#/c/230986/

Note in the upper right hand there is a list of all the related patches.
Make sure you are on the top patch of the list. This is a branch. Click on
the download menu. Beside the checkout there is a URL and a little button.
Click the button, and the following is put in your paste buffer:

git fetch ssh://ff...@review.gerrithub.io:29418/ffilz/nfs-ganesha
refs/changes/90/230990/2 && git checkout FETCH_HEAD

I amend that to:

git fetch ssh://ff...@review.gerrithub.io:29418/ffilz/nfs-ganesha
refs/changes/90/230990/2 && git checkout -b ffilz FETCH_HEAD

And boom, there's an ffilz branch in my repo.

I understand git-review makes this even easier. I'm sure there's other
tricks too.

Thanks

Frank








--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292

Re: [Nfs-ganesha-devel] posix_find_parent() routine logic error

[Frank Filz]

Could you see if the top patch in this branch fixes the problem?

 

https://github.com/ffilz/nfs-ganesha/commits/find-parent

 

Thanks

 

Frank

 

From: Krishna Harathi [mailto:khara...@exablox.com] 
Sent: Tuesday, May 5, 2015 3:29 PM
To: nfs-ganesha-devel@lists.sourceforge.net
Subject: [Nfs-ganesha-devel] posix_find_parent() routine logic error

 

In  the outcome of this routine, "/exports/nfs10" is resulting as child of 
"/exports/nfs1"

instead of child of "/exports" as seen in the log entries (shown below). 

Ganesha exits with CRIT error later, unable to claim /exports/nfs10.

 

05/05/2015 14:39:40 : epoch 5549389c : oneblox-40079 : ganesha.nfsd-20428[main] 
posix_find_parent :FSAL :INFO :File system /exports/nfs10 is a child of 
/exports/nfs1

05/05/2015 14:39:40 : epoch 5549389c : oneblox-40079 : ganesha.nfsd-20428[main] 
posix_find_parent :FSAL :INFO :File system /exports/nfs1 is a child of /exports

We are using Ganesha 2.1.0, but this routine is not changed in 2.2.0.

Any help in fixing this is appreciated.




Regards.

Krishna Harathi

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Please review the FSAL API extensions in support of multiple file descriptors

[Frank Filz]

This probably needs a lot of work, but I want to get discussion going:

https://review.gerrithub.io/232543

Thanks

Frank




--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Current staging for V2.3-dev-2

[Frank Filz]

Last week, I just went ahead and staged and then pushed the merge for dev-1
on Thursday, this week, I thought I'd do things a bit differently.

This is my current staging branch:

https://github.com/ffilz/nfs-ganesha/commits/next

This branch has passed pynfs (4.0 with 1 expected failure and 4.1 with 15
expected failures)

On gerrithub you can see all the open patches. Any patch that has both CR
and V checked is being staged:

https://review.gerrithub.io/#/q/status:open+project:ffilz/nfs-ganesha+branch
:next

Any patch that has +1 review and checked verify is a candidate for staging.
I hope to have all patches verified, though I may occasionally grant a +1
verify so I can stage a patch. When I grant a +2 review, that checks CR and
sets up the patch for staging.

I will give some opportunity for additional patches this week before
tagging.

I'd also love some feedback on this process.

Thanks

Frank



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Current staging for V2.3-dev-2

[Frank Filz]

Ah, and I spoke too soon, now we get to test the Thursday staging...

This patch:

https://review.gerrithub.io/#/c/232104/

failed checkpatch for me despite getting approval from Dominique's run...

I have unstaged it for now, though have not pushed a new next without it...

Thanks

Frank

> -Original Message-
> From: Frank Filz [mailto:ffilz...@mindspring.com]
> Sent: Thursday, May 7, 2015 11:28 AM
> To: nfs-ganesha-devel@lists.sourceforge.net
> Subject: [Nfs-ganesha-devel] Current staging for V2.3-dev-2
> 
> Last week, I just went ahead and staged and then pushed the merge for dev-
> 1 on Thursday, this week, I thought I'd do things a bit differently.
> 
> This is my current staging branch:
> 
> https://github.com/ffilz/nfs-ganesha/commits/next
> 
> This branch has passed pynfs (4.0 with 1 expected failure and 4.1 with 15
> expected failures)
> 
> On gerrithub you can see all the open patches. Any patch that has both CR
> and V checked is being staged:
> 
> https://review.gerrithub.io/#/q/status:open+project:ffilz/nfs-
> ganesha+branch
> :next
> 
> Any patch that has +1 review and checked verify is a candidate for
staging.
> I hope to have all patches verified, though I may occasionally grant a +1
verify
> so I can stage a patch. When I grant a +2 review, that checks CR and sets
up
> the patch for staging.
> 
> I will give some opportunity for additional patches this week before
tagging.
> 
> I'd also love some feedback on this process.
> 
> Thanks
> 
> Frank
> 
> 
> 
>

--
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-2

[Frank Filz]

Branch next

Tag:V2.3-dev-2

Highlights

* FSAL_GPFS: Add validation checking when setting ACLs

* Add some V2.2.0 changelogs that got missed

* Add state_t management for 9P and NLM in preparation for multiple fds

Signed-off-by: Frank S. Filz 

Contents:

c144e3a Frank S. Filz V2.3-dev-2
b56140a Allison Henderson Add validation checking when setting ACLs
a5b2ad6 Philippe DENIEL Debian: update src/debian/changelog to add records
related to 2.2
c4f06b0 Philippe DENIEL RPM: Update %changelog record in specfile
25a5499 Frank S. Filz Fix posix_find_parent to differentiate when /fs1 and
/fs10 are filesystems
b45cf40 Frank S. Filz Use state_t for NLM share reservations
4e2d5bb Frank S. Filz Use state_t for NLM and 9P locks
0fbed65 Frank S. Filz Embed a state_t in 9P fid structure
2b9a19b Frank S. Filz Introduce state types for NLM state_t with hash table
and related functions
b0273a5 Frank S. Filz Refine interface for hashtable_deletelatched to always
retain the latch.
288c9de Malahal Naineni Remove incorrect reference decrement on clientid


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Gerrit code review and verify procedures

[Frank Filz]

As we get more into this, I think we need to work on some procedures.

Please don't give your own patches +1 Code Review or Verify (unless the
Verify +1 comes from an automated test that posts it's own review to
Gerrithub).

When it comes time to stage patches for a week's release, I will make
decisions about patches that haven't been verified, that will not block me
from taking them.

Note that when I stage patches, I will +2 Code Review them. That is an
exception to reviewing your own patches, however, I will never +2 Code
Review one of my patches that hasn't been satisfactorily reviewed by others.

Thanks

Frank



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] This weeks merge

[Frank Filz]

At the moment, there's not very much to merge this week. While the goal of
doing a staging merge Thursday is admirable to give folks a chance to
respond to issues that arise from my build and test, if there's nothing to
merge, there's nothing to gain by merging early.

Thus this week, I encourage if you have a patch you think could be ready by
Friday 12:00 PM Pacific Time, please make sure it gets independent review
and verify. If there are patches that hit common code, I can verify as part
of my staging.

Candidates for this week:

I think at least some of the FSAL_GLUSTER stuff could be ready
There is some minor FSAL_GPFS stuff that just needs a code review from
someone else working with GPFS
Allison has a patch that Malahal and I will review
Philippe has an update to nfsv41.h for Flex Files, I think that can go in,
but I'd like at least one other pNFS person to look at it

Thanks

Frank


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] This weeks merge

[Frank Filz]

> Please merge https://review.gerrithub.io/#/c/233370/ as this needs to be
> brought into 2.2-stable as well (ASAP). [Kaleb?]

This patch needs the commit message fixed before merge.

Thanks

Frank

> On 05/14/2015 10:37 PM, Frank Filz wrote:
> > At the moment, there's not very much to merge this week. While the
> > goal of doing a staging merge Thursday is admirable to give folks a
> > chance to respond to issues that arise from my build and test, if
> > there's nothing to merge, there's nothing to gain by merging early.
> >
> > Thus this week, I encourage if you have a patch you think could be
> > ready by Friday 12:00 PM Pacific Time, please make sure it gets
> > independent review and verify. If there are patches that hit common
> > code, I can verify as part of my staging.
> >
> > Candidates for this week:
> >
> > I think at least some of the FSAL_GLUSTER stuff could be ready There
> > is some minor FSAL_GPFS stuff that just needs a code review from
> > someone else working with GPFS Allison has a patch that Malahal and I
> > will review Philippe has an update to nfsv41.h for Flex Files, I think
> > that can go in, but I'd like at least one other pNFS person to look at
> > it
> >
> > Thanks
> >
> > Frank
> >
> >
> > --
> >  One dashboard for servers and applications across
> > Physical-Virtual-Cloud Widest out-of-the-box monitoring support with
> > 50+ applications Performance metrics, stats and reports that give you
> > Actionable Insights Deep dive visibility with transaction tracing
> > using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-3

[Frank Filz]

Branch next

Tag:V2.3-dev-3

Highlights

* Prevent mode attribute from wiping out inherited ACL on create

* GPFS config and packaging changes

* Log a message when callback channel is marked down

Signed-off-by: Frank S. Filz 

Contents:

353efbf Frank S. Filz V2.3-dev-3
7fa5a1a Malahal Naineni gpfs: Increase the rpc max connections to 1
bb42b14 Poornima Gupte Added Ports to the gpfs main config file. Also added
COMPONENT block in the gpfs log config file.
c4c5630 Malahal Naineni Add nfs-ganesha-gpfs script to gpfs fsal rpm
839ed74 Malahal Naineni Log a message when callback channel is marked down.
7d239b4 Allison Henderson Fix aces inherited on create


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] CMake fails in 2.3-dev-3

[Frank Filz]

> The latest tag has an error in CMakeLists.txt, cmake -
> DUSE_FSAL_GLUSTER=ON -DCURSES_LIBRARY=/usr/lib64 -
> DCURSES_INCLUDE_PATH=/usr/include/ncurses -
> DCMAKE_BUILD_TYPE=Maintainer -DUSE_DBUS=ON /root/nfs-ganesha/src/
> CMake Error: Error in cmake code at
> /root/nfs-ganesha/src/CMakeLists.txt:1310:
> Parse error.  Function missing ending ")".  End of file reached.
> 
> 
> This is due to a typo in line 38 of /src/CMakeLists.txt. The diff is pasted 
> here,
> 
> -set(GANESHA_EXTRA_VERSION -dev-3
> +set(GANESHA_EXTRA_VERSION -dev-3)

Oh, crud...

If someone is good at scripting, we could really use some things to help 
automate the bits for putting out a weekly build.

I wish we could just get the version information from the signed tag instead of 
having to manually change CMakeLists.txt.

I will put out a dev-3.1 tag shortly.

Frank




--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] system max fd and Cache Inode parameter

[Frank Filz]

> Krishna Harathi [khara...@exablox.com] wrote:
> >I am trying to determine the relation between the system imposed
limit
> of
> >max FDs (4096 now) and
> >the Cache Inode HW Mark (10 default).
> >In a test work load, I am getting errno 24 (too many open files)
error
> >returned,
> >and here is our current settings.
> >15/05/2015 18:48:23 : epoch 5556a1e7 : OneBlox-0333 :
> >nfs-ganesha-12814[main] cache_inode_lru_pkginit :INODE LRU :INFO
> >:Attempting to increase soft limit from 1024 to hard limit of 4096
> >15/05/2015 18:48:23 : epoch 5556a1e7 : OneBlox-0333 :
> >nfs-ganesha-12814[main] cache_inode_lru_pkginit :INODE LRU :INFO
> :Setting
> >the system-imposed limit on FDs to 4096
> >I looked at the related code in Cache_inode but could not determine
the
> >relationship between
> >the system limit and cache_inode or how many file FDs Ganesha will
try to
> >open.
> >Any help is (1) What is the system limit to be set, given the default
> >cache inode HWmark?
> 
> Cache inode entries can exist without the corresponding file being open.
> So I don't think there is a relation between  Entries_HWMark and the
> number of file descriptors a process can open.
> 
> >(2) For the given system limit, what is the cache inode setting. We
are
> >using Ganesha 2.1.
> 
> The number of cache entries is probably related to the available system
> memory rather than the number of files a process can open. Frank or anyone
> else, what is a good value on systems with 128GB or 256GB system memory?

A good number of cache inodes probably depends on a lot of things.

One thing to consider is if you have lots of large directories that will be
enumerated with READDIR is that you probably need at least twice that many
cache inodes to prevent READDIR from upchucking all over the floor.

When multiple filedescriptors come in, we will really need to make sure we
can have as many open files as possible since there will be lots of extra
open files.

Frank


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] CMake fails in 2.3-dev-3

[Frank Filz]

> Meghana Madhusudhan [mmadh...@redhat.com] wrote:
> > Hi,
> >
> > The latest tag has an error in CMakeLists.txt, cmake
> > -DUSE_FSAL_GLUSTER=ON -DCURSES_LIBRARY=/usr/lib64
> > -DCURSES_INCLUDE_PATH=/usr/include/ncurses
> > -DCMAKE_BUILD_TYPE=Maintainer -DUSE_DBUS=ON /root/nfs-
> ganesha/src/
> > CMake Error: Error in cmake code at
> > /root/nfs-ganesha/src/CMakeLists.txt:1310:
> > Parse error.  Function missing ending ")".  End of file reached.
> >
> >
> > This is due to a typo in line 38 of /src/CMakeLists.txt. The diff is
> > pasted here,
> >
> > -set(GANESHA_EXTRA_VERSION -dev-3
> > +set(GANESHA_EXTRA_VERSION -dev-3)
> 
> Looks like we have a process issue here. How come this wasn't detected
> prior this making it there!

The problem is that I do this stuff AFTER all the testing (because I can't
tag etc. until all the testing is done in case I need to unstage something).
I will add a make install to my manual script, but the process problem
ultimately is a finicky set of manual steps. Any manual process with more
than two or three steps is prone to messing up.

The manual steps in as detailed as I can remember to putting out weekly
release:

"download" each set of related patches from gerrithub
Rebase each on top of next and merge (to simulate cherrypick)
scripts/pycheckpatch -a V2.3-dev-2.. 
make install
Run pynfs nfs4.0
Run pynfs nfs4.1
Maybe run cthon04 on nfs3 (bad boy Frank, I rarely run this)
Maybe run cthon04 on nfs4 (even worse I almost never run this)
Maybe run cthon04 on nfs4.1 (or this...)
Edit CMakeLists.txt to indicate latest build is dev-3
make install (I haven't been doing this but obviously I need to)
git commit --author "Frank S. Filz " --signoff -a
type V2.3-dev-3 (or whatever) as commit message
git log --pretty=format:"%h %an %s" V2.3-dev-2..
Use that to type up commit message for signed tag, remembering to type
V2.3-dev-3 into that too...
That message gets typed into the file ../../2.2-dev-tag so I can easily use
it later in typing up the release announcement message
su ffilz /home/ffilz/bin/tag_release -f V2.3-dev-3
git push https://github.com/nfs-ganesha/nfs-ganesha.git next
git push https://github.com/nfs-ganesha/nfs-ganesha.git V2.3-dev-3
git push gerrit next
git push origin next
git fetch ganesha (to update this local repo with the nfs-ganesha next)
echo Announce Push of V2.3-dev-3 ; echo ; echo Branch next ; echo ; echo -n
Tag: ; cat ../../2.2-dev-tag ; echo Contents: ; echo ; git log
--pretty=format:"%h %an %s" V2.3-dev-2..
copy and paste that into the release e-mail and move the "Announce..." bit
into the subject

Some of these steps I have in my little git shortcuts file, but I have to
edit that every week to change dev-3 to dev-4 and dev-2 to dev-3...

Frank



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-3.1

[Frank Filz]

Branch next

Tag:V2.3-dev-3

Highlights

* Prevent mode attribute from wiping out inherited ACL on create

* GPFS config and packaging changes

* Log a message when callback channel is marked down

Signed-off-by: Frank S. Filz 

Contents:

3531dae Frank S. Filz V2.3-dev-3.1 - repair CMakeLists.txt


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Review required and warning for this weeks build

[Frank Filz]

Philippe pushed a patch that brings in a new version of checkpatch.pl.

I have updated that patch with a couple more config changes plus also
brought in spelling.txt.

Then I used scripts/runcp.sh to check all our existing code (and updated
that with some new things to ignore).

This resulted in a huge number of changes to conform to the new checks.

The significant new checks to be aware of:

Strings now should not be line-broken to fit in 80 columns. The one
exception is the long strings used to document command line options
(runcp.sh will still trip on these, just ignore those few errors).

A blank line must follow local variable declarations. Note that
checkpatch.pl gets confused by some of our types, you can use a comment
instead of a blank line to keep all the declarations in one block. This also
impacts a few structures.

A return at the end of a void function is no longer allowed. For a totally
empty function, you can put a comment that suggests the function has nothing
to do (I'd like to eventually eliminate most of these empty functions).

A break after a goto or return is not allowed.

There are some other things I also fixed.

I will be merging other patches after this block this week. I will deal with
any manual merges and also fix up your patch in case it trips on any of the
new checks.

Thanks

Frank


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] About NULLFS refurbishment (and considerations on FSAL API design)

[Frank Filz]

> Hi,
> I've just posted a set of patches (changes 234113 to 234122) to replace the
> field "attributes" in fsal_obj_handle by a pointer. This first set corrects 
> every
> other layers than Fsal. I only updated a few Fsals (Vfs, Pseudo, Nullfs) as
> examples, I'm waiting for some feedback on what I've already posted before
> doing the others. I added some code to ensure backward compatibility of
> unpatched Fsals for now.
> 
> It would be great if the community could send reviews quickly. These
> changes could be quite painful to rebase as they modify many files, so I hope
> they won't stay on gerrithub for too long.

One thing I dislike is all the "access" methods we have that just look at the 
same place all the time...

I'd prefer we just directly access the new pointer.

Also, I would make the first patch to all FSALs just be to set that pointer to 
&obj_hdl->attributes.

Then change the upper layers to all access attributes via the pointer.

Then start changing FSALs to include the attributes in their private 
object_handle and set the pointer to that and also change each FSAL to access 
via the pointer.

This way each bit of code only gets changed once, but it is still bisectable.

Frank

> -Message d'origine-
> De : DENIEL Philippe [mailto:philippe.den...@cea.fr] Envoyé : jeudi 9 avril
> 2015 18:01 À : nfs-ganesha-devel@lists.sourceforge.net
> Cc : Frank Filz; GREGOIRE PICHON; Vincent Saulue Laborde Objet : About
> NULLFS refurbishment (and considerations on FSAL API design)
> 
> Hi,
> 
> recently people from the Atos/Bull company start reworking the stackable
> FSAL feature, which is broken since 2.0 with the new FSAL design.
> They pushed several commits for review in gerrithub (look for
> https://review.gerrithub.io/#/q/owner:Vincent.Saulue%2540bull.net+status
> :open
> for details).
> In this refurbishment process (see
> https://review.gerrithub.io/#/c/221464/), they had to copy the handle
> attributes in the FSAL_NULL object : the NULLFS module does not manage
> attributes but has to get them from the FSAL on which it is stacked.
> This copy process (look for function nullfs_copy_attrlist() ) they explicitly
> recopy a standard struct attrlist from the underlying FSAL to the stacked
> FSAL. Discussion started on that point, and the key issue is
> : we should not copy attrlist for consistency/refcount reasons, the FSAL on
> top should the one underneath and manage a pointer to the underlying
> FSAL's attrlist object.
> I was agree on that point, and thenI started discussing with Vincent and
> Grégoire and changed by point of view.
> 
> If you look at Ganesha code, there are bunches of locations where you see
> code like this :
>  entry->obj_handle->attributes. where "entry" is of 
> type
> "cache_entry_t *".
> 
> This means, that  a fsal_obj must have a "struct attrlist" in it and can't 
> have a
> "struct attrlist *" instead. This makes it impossible to reference the
> underlying FSAL's attrlist from a stacked FSAL. In order to do this we should
> provide FSAL API with an accessors method (a macro or a static inline
> function) to get the attrlist from a fsal_obj. This way, standard FSAL and
> stackable FSAL would have different accessors and the second one could do
> a clean reference to the underlying FSAL. This is no big change, but it 
> touches
> many places.
> For wanting of such a modification in FSAL API, we must keep the
> nullfs_copy_attrlist() function. This implies that:
>  - a FSAL accessed through a stacked FSAL can access the same directory
> directly (this way, the only object to exist in cache inode refers fsal_obj 
> that
> belongs to the stackable FSAL)
>  - we should establish barriers and strong warnings to make sure that such
> a situation won't occur. This can be done at config parsing time.
> 
> Regarding timeline : NULLFS FSAL has to exist for it will be the "mother of
> every other stackable FSALs", but it is not required for 2.2 . We can postpone
> it as a 2.3 feature.
> 
> Any comments/discussion are welcome.
> 
>  Regards
> 
>  Philippe
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.so

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

> On Thu, May 21, 2015 at 11:59 PM, Anand Subramanian
>  wrote:
> > On 05/22/2015 04:27 AM, edison su wrote:
> >>
> >> Hi all,
> >> I am following the doc @
> >> https://github.com/nfs-ganesha/nfs-ganesha/wiki/Cluster-DRC, but
> >> can't figure out how to setup a cluster ganesha.
> >> Is the feature already implemented yet, or still in the development?
> >> If it's implemented already, is there any document about how to setup
> >> it up?
> >> I am using Gluster as FSAL, I looked at
> >>
> >>
> http://www.gluster.org/community/documentation/index.php/Features/H
> A_
> >> for_ganesha, but nothing specific about how to use it.
> >> Appreciate any help, thanks.
> >>
> > Hi Edison,
> >
> > Several aspects here:
> >
> > 1. Cluster-DRC is one feature in getting ganesha in clustered mode
> > completely failproof - at least, that was the original intent behind
> > this feature. But in subsequent discussions in the ganesha community
> > it was not deemed to be a must-have feature to get clustered-mode
> > ganesha working as per current requirements. This consideration was to
> > an extent, based on the fact that no data loss or catastrophic
> > incidents have been reported in the community due to lack of
cluster-drc.
> 
> Thanks for the clarification. Without DRC implementation, does it implies
> that, NFS v4 server state will not be maintained during failover? Such as
file
> locking state etc.
> Just trying to figure out, will nfs-ganesha, in the cluster mode,
duplicate NFS
> v4 server state throughout the cluster.
> If so, how is it implemented?

No, Ganesaha relies on NFS state reclaim to migrate state.

The takeip and releaseip interface facilitates this. Releaseip is necessary
when an IP is failed over without node failure, or for node failback. In
either case, Ganesha is still running on the node giving up the ip, and thus
it must release state in order for it to be reclaimable on the node that
takes the ip.

DRC is independent of the issues with state. The most critical DRC issue
(which unfortunately is very hard to solve and part of why cluster DRC was
abandoned) is the following scenario:

Client does write to node1
Node1 commits write to disk, but fails before it can send response (or log
DRC)
Node2 takes over
Someone else does a write to the same file (perhaps even having read the
modified data)
Client retries it's write

Frank


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

> On Thu, May 21, 2015 at 7:59 PM, Malahal Naineni 
> wrote:
> > edison su [sudi...@gmail.com] wrote:
> >> Hi all,
> >> I am following the doc @
> >> https://github.com/nfs-ganesha/nfs-ganesha/wiki/Cluster-DRC, but
> >> can't figure out how to setup a cluster ganesha.
> >
> > Ganesha is not cluster aware at this time other than supporting
> > release IP and take IP/node dbus operations which are used in
> > failover/failback cases. Anand is working on cluster aware ganesha but
> > it is still in design phase.
> 
> So is there no NFSv4 state maintained after failover? Does community have
> the plan to implement cluster-aware ganesha, such as duplicate NFSv4 state
> throughout cluster?

That is impractical without special hardware, and even then, would likely be
too costly to performance.

Frank



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] This weeks upcoming build

[Frank Filz]

I will be posting dev-4 later today.

In the meantime, it will JUST be the checkpatch updates.

It looks like all patches should be rebased and verified against the new
checkpatch for inclusion in dev-5 (or later...). Please use:

scripts/pycheckpatch -a V2.3-dev-4..

And verify the patches in your branch pass after rebasing before pushing new
versions of your patches.

Note that checkpatch.conf has changed, please make sure you get the latest
where it needs to be.

Note that next week I am out Monday-Wednesday. I will try to keep tabs on
things a bit, but can't make any promises.

Thanks

Frank



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-4

[Frank Filz]

Branch next

Tag:V2.3-dev-4

Highlights

* New version of checkpatch with spelling check also

* Update code to pass new checkpatch as much as reasonable

* Update runcp.sh to ignore specific warnings on specific files

Signed-off-by: Frank S. Filz 

Contents:

40d954c Frank S. Filz V2.3-dev-4
91cc2ed Frank S. Filz Update runcp.sh to ignore some new checkpatch errors
on specific files
a1726fb Philippe DENIEL Replace checkpatch.pl by a newer version (from
kernel source).
12eb623 Frank S. Filz Fix new checkpatch errors in dbus code
40894f1 Frank S. Filz Fix new checkpatch errors in multilock tool
be54a56 Frank S. Filz Fix new checkpatch errors in test directory
29cc9e4 Frank S. Filz Fix new checkpatch errors in support directory
f12f5b8 Frank S. Filz Fix new checkpatch errors in SAL directory
1b9031c Frank S. Filz Fix new checkpatch errors in RPCAL directory
f19d789 Frank S. Filz Fix new checkpatch errors in Protocols/RQUOTA code
473e04c Frank S. Filz Fix new checkpatch errors in Protocols/NLM code
2891503 Frank S. Filz Fix new checkpatch errors in Protocols/NFS shared code
8fb47a8 Frank S. Filz Fix new checkpatch errors in Protocols/NFS v4 code
cd11966 Frank S. Filz Fix new checkpatch errors in Protocols/NFS nfs v3 code
baa47bf Frank S. Filz Fix new checkpatch errors in mount code
a1b82a7 Frank S. Filz Fix new checkpatch errors in 9p code (across several
directories)
066ab53 Frank S. Filz Fix new checkpatch errors in linux and freebsd
specific code
aa429bb Frank S. Filz Fix new checkpatch errors in log code
33be2e2 Frank S. Filz Fix new checkpatch errors in MainNFSD code
dbc775a Frank S. Filz Fix new checkpatch errors in include files
edeb640 Frank S. Filz Fix new checkpatch errors in FSAL_PSEUDO
2debecf Frank S. Filz Fix new checkpatch errors in idmapper
35f67e9 Frank S. Filz Fix new checkpatch errors in hashtable
92b1141 Frank S. Filz Fix new checkpatch errors in cache_inode
ea7fcd8 Frank S. Filz Fix new checkpatch errors in FSAL common code
09ab3bf Frank S. Filz Fix new checkpatch errors in FSAL_UP
51d1a8e Frank S. Filz Fix new checkpatch errors in FSAL_NULL
8d62408 Frank S. Filz Fix new checkpatch errors in FSAL_ZFS
666e41c Frank S. Filz Fix new checkpatch errors in FSAL_VFS
dbb8fea Frank S. Filz Fix new checkpatch errors in FSAL_PT
1f12e09 Frank S. Filz Fix new checkpatch errors in FSAL_PROXY
c971c8c Frank S. Filz Fix new checkpatch errors in FSAL_LUSTRE
edb79fc Frank S. Filz Fix new checkpatch errors in FSAL_GPFS
0cf4823 Frank S. Filz Fix new checkpatch errors in FSAL_CEPH
354baf7 Frank S. Filz Fix new checkpatch errors in FSAL_GLUSTER
4507831 Frank S. Filz Remove GLUSTER_VALIDATE_RETURN_STATUS macro that does
a return inside


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] More new checkpatch

[Frank Filz]

Looks like we're seeing a lot of commit messages that have not been properly
wrapped.

Please revisit your commit messages and make sure they are properly line
wrapped. It's helpful to everyone.

Thanks

Frank


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

None of these state items are preserved in failover. Ganesha exclusively relies 
on state recovery to migrate state to failover node. 

Frank

Sent from my iPhone

On May 26, 2015, at 3:17 PM, edison su  wrote:

> On Tue, May 26, 2015 at 3:35 AM, Anand Subramanian  
> wrote:
>> On 05/22/2015 10:42 PM, edison su wrote:
>>> 
>>> On Thu, May 21, 2015 at 11:59 PM, Anand Subramanian 
>>> wrote:
 
 On 05/22/2015 04:27 AM, edison su wrote:
> 
> Hi all,
> I am following the doc @
> https://github.com/nfs-ganesha/nfs-ganesha/wiki/Cluster-DRC, but can't
> figure out how to setup a cluster ganesha.
> Is the feature already implemented yet, or still in the development?
> If it's implemented already, is there any document about how to setup
> it up?
> I am using Gluster as FSAL, I looked at
> 
> 
> http://www.gluster.org/community/documentation/index.php/Features/HA_for_ganesha,
> but nothing specific about how to use it.
> Appreciate any help, thanks.
> 
 Hi Edison,
 
 Several aspects here:
 
 1. Cluster-DRC is one feature in getting ganesha in clustered mode
 completely failproof - at least, that was the original intent behind this
 feature. But in subsequent discussions in the ganesha community it was
 not
 deemed to be a must-have feature to get clustered-mode ganesha working as
 per current requirements. This consideration was to an extent, based on
 the
 fact that no data loss or catastrophic incidents have been reported in
 the
 community due to lack of cluster-drc.
>>> 
>>> Thanks for the clarification. Without DRC implementation, does it
>>> implies that, NFS v4 server state will not
>>> be maintained during failover? Such as file locking state etc.
>>> Just trying to figure out, will nfs-ganesha, in the cluster mode,
>>> duplicate NFS v4 server state throughout the cluster.
>>> If so, how is it implemented?
>>> 
 2. CMAL is the cluster manager abstraction layer which is meant to help
 ganesha setup its own cluster of ganesha heads (what you can call
 active-active ganesha with HA) by setting up its own cluster (the user is
 free to choose the cluster manager etc.) or it enables ganesha to join an
 existing cluster seamlessly. This effectively helps ganesha or a cluster
 of
 ganesha heads integrate with/cater to both clustered and non-clustered
 filesystem backends. For the most part the design is finalized and the
 implementation underway. This is not yet a must for using ganesha in
 clustered mode (See (3) below). The availability of CMAL enables ganesha
 to
 talk to CM (Cluster Manager) backends in an integrated way. It is modeled
 on
 the FSAL layer (for design abstraction and extensibility purposes).
>>> 
>>> If DRC is not implemented, then is CMAL API changed? From the doc:
>>> https://github.com/nfs-ganesha/nfs-ganesha/wiki/Cluster-DRC, CMAL API
>>> has add_drc_entry and retrieve_drc_entries, I think it's DRC specific,
>>> right?
>>> If API is changed, then what's the latest CMAL api? Are just init_cmal
>>> and shutdown_cmal used by cluster manager integration?
>>> 
 3. Ganesha + Gluster is a different story. ganesha+gluster in clustered
 mode
 is for the most part ready. There are some bits which are in upstream
 review. You already have one of the central links to this feature (in
 your
 note). There is a gluster-ganesha script that automatically sets up a
 cluster of ganesha heads so that you can have active-active HA with upto
 16
 ganesha heads for a GlusterFS storage pool. The script etc. are all
 available in upstream Gluster community version 3.7. Let me know if you
 want
 to try GlusterFS 3.7 with the current nfs-ganesha version and I will be
 glad
 to provide you with further info. This solution automatically sets up a
 cluster of ganesha heads for V3 and/or V4 for use with GlusterFS and uses
 Pacemaker/Corosync as the Cluster Manager. My suggestion is you should
 start
 with downloading glusterfs 3.7 and you will find the ganesha-ha.sh script
 I
 am talking about.
>>> 
>>> From the doc, it looks like, Ganesha + Gluster HA, is like ordinary
>>> Pacemaker/coreasync cluster setup, not much specific to nfs-ganesha?
>>> Correct me if I am wrong about how HA works: pacemaker will
>>> automatically start/stop nfs-ganesha service in the cluster in case of
>>> failover, through few scripts. There is no NFS server state maintained
>>> after failover, in case of NFSV4, right?
>>> I'll take a look at gulsterfs 3.7, thanks for your suggestion. It's
>>> really helpful for me to understand how the things work.
>>> 
>> 
>> There is more to it than just that. Pacemaker and corosync simply manage the
>> cluster of ganesha heads for a GlusterFS trusted storage pool.
>> There is a HA conf file you can use to setup the cluster of nfs server heads
>> any way 

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

I think that's just documenting the support Gluster has to allow multiple node 
cluster of Ganesha so state is reflected across all the cluster nodes. But to 
accomplish a failover Ganesha itself either has to share all the gory details 
of state or it has to rely on the server failure mechanism built into NFS. 

Frank 

Sent from my iPhone

On May 26, 2015, at 4:09 PM, edison su  wrote:

> Hmm, interesting. Gluster's
> doc(http://www.gluster.org/community/documentation/index.php/Features/Upcall-infrastructure),
> it does maintain
> lock and file delegation state. Do I read the doc wrong?
> 
> On Tue, May 26, 2015 at 3:34 PM, Frank Filz  wrote:
>> None of these state items are preserved in failover. Ganesha exclusively 
>> relies on state recovery to migrate state to failover node.
>> 
>> Frank
>> 
>> Sent from my iPhone
>> 
>> On May 26, 2015, at 3:17 PM, edison su  wrote:
>> 
>>> On Tue, May 26, 2015 at 3:35 AM, Anand Subramanian  
>>> wrote:
>>>> On 05/22/2015 10:42 PM, edison su wrote:
>>>>> 
>>>>> On Thu, May 21, 2015 at 11:59 PM, Anand Subramanian 
>>>>> wrote:
>>>>>> 
>>>>>> On 05/22/2015 04:27 AM, edison su wrote:
>>>>>>> 
>>>>>>> Hi all,
>>>>>>> I am following the doc @
>>>>>>> https://github.com/nfs-ganesha/nfs-ganesha/wiki/Cluster-DRC, but can't
>>>>>>> figure out how to setup a cluster ganesha.
>>>>>>> Is the feature already implemented yet, or still in the development?
>>>>>>> If it's implemented already, is there any document about how to setup
>>>>>>> it up?
>>>>>>> I am using Gluster as FSAL, I looked at
>>>>>>> 
>>>>>>> 
>>>>>>> http://www.gluster.org/community/documentation/index.php/Features/HA_for_ganesha,
>>>>>>> but nothing specific about how to use it.
>>>>>>> Appreciate any help, thanks.
>>>>>>> 
>>>>>> Hi Edison,
>>>>>> 
>>>>>> Several aspects here:
>>>>>> 
>>>>>> 1. Cluster-DRC is one feature in getting ganesha in clustered mode
>>>>>> completely failproof - at least, that was the original intent behind this
>>>>>> feature. But in subsequent discussions in the ganesha community it was
>>>>>> not
>>>>>> deemed to be a must-have feature to get clustered-mode ganesha working as
>>>>>> per current requirements. This consideration was to an extent, based on
>>>>>> the
>>>>>> fact that no data loss or catastrophic incidents have been reported in
>>>>>> the
>>>>>> community due to lack of cluster-drc.
>>>>> 
>>>>> Thanks for the clarification. Without DRC implementation, does it
>>>>> implies that, NFS v4 server state will not
>>>>> be maintained during failover? Such as file locking state etc.
>>>>> Just trying to figure out, will nfs-ganesha, in the cluster mode,
>>>>> duplicate NFS v4 server state throughout the cluster.
>>>>> If so, how is it implemented?
>>>>> 
>>>>>> 2. CMAL is the cluster manager abstraction layer which is meant to help
>>>>>> ganesha setup its own cluster of ganesha heads (what you can call
>>>>>> active-active ganesha with HA) by setting up its own cluster (the user is
>>>>>> free to choose the cluster manager etc.) or it enables ganesha to join an
>>>>>> existing cluster seamlessly. This effectively helps ganesha or a cluster
>>>>>> of
>>>>>> ganesha heads integrate with/cater to both clustered and non-clustered
>>>>>> filesystem backends. For the most part the design is finalized and the
>>>>>> implementation underway. This is not yet a must for using ganesha in
>>>>>> clustered mode (See (3) below). The availability of CMAL enables ganesha
>>>>>> to
>>>>>> talk to CM (Cluster Manager) backends in an integrated way. It is modeled
>>>>>> on
>>>>>> the FSAL layer (for design abstraction and extensibility purposes).
>>>>> 
>>>>> If DRC is not implemented, then is CMAL API changed? From the doc:
>>>>> https://github.com/nfs-ganesha/nfs-ganesha/wiki/Cluster-DRC, CMAL API
>>>>> has 

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

> On Tue, May 26, 2015 at 5:04 PM, edison su  wrote:
> > Could you elaborate the "server failure mechanism build into NFS"?
> > Without sharing state with other node, how the failover can happen
> > correctly? I know, in NFSv2 and V3, for the stateless NFS server, the
> > failover should be easy. But in NFSv4, there are lot of states are
> > maintained by NFS server, for proper failover, these states needed to
> > be saved in somewhere.
> 
> Does the "server failure mechanism build into NFS" mean something like
> state reclaim specified in NFSV4.1 8.4.2.1?

Yes.

Frank

> >
> >
> > On Tue, May 26, 2015 at 4:50 PM, Frank Filz 
> wrote:
> >> I think that's just documenting the support Gluster has to allow multiple
> node cluster of Ganesha so state is reflected across all the cluster nodes. 
> But
> to accomplish a failover Ganesha itself either has to share all the gory 
> details
> of state or it has to rely on the server failure mechanism built into NFS.
> >>
> >> Frank
> >>
> >> Sent from my iPhone
> >>
> >> On May 26, 2015, at 4:09 PM, edison su  wrote:
> >>
> >>> Hmm, interesting. Gluster's
> >>>
> doc(http://www.gluster.org/community/documentation/index.php/Feature
> >>> s/Upcall-infrastructure),
> >>> it does maintain
> >>> lock and file delegation state. Do I read the doc wrong?
> >>>
> >>> On Tue, May 26, 2015 at 3:34 PM, Frank Filz 
> wrote:
> >>>> None of these state items are preserved in failover. Ganesha
> exclusively relies on state recovery to migrate state to failover node.
> >>>>
> >>>> Frank
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>> On May 26, 2015, at 3:17 PM, edison su  wrote:
> >>>>
> >>>>> On Tue, May 26, 2015 at 3:35 AM, Anand Subramanian
>  wrote:
> >>>>>> On 05/22/2015 10:42 PM, edison su wrote:
> >>>>>>>
> >>>>>>> On Thu, May 21, 2015 at 11:59 PM, Anand Subramanian
> >>>>>>> 
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> On 05/22/2015 04:27 AM, edison su wrote:
> >>>>>>>>>
> >>>>>>>>> Hi all,
> >>>>>>>>> I am following the doc @
> >>>>>>>>> https://github.com/nfs-ganesha/nfs-ganesha/wiki/Cluster-DRC,
> >>>>>>>>> but can't figure out how to setup a cluster ganesha.
> >>>>>>>>> Is the feature already implemented yet, or still in the
> development?
> >>>>>>>>> If it's implemented already, is there any document about how
> >>>>>>>>> to setup it up?
> >>>>>>>>> I am using Gluster as FSAL, I looked at
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> http://www.gluster.org/community/documentation/index.php/Featu
> >>>>>>>>> res/HA_for_ganesha, but nothing specific about how to use it.
> >>>>>>>>> Appreciate any help, thanks.
> >>>>>>>>>
> >>>>>>>> Hi Edison,
> >>>>>>>>
> >>>>>>>> Several aspects here:
> >>>>>>>>
> >>>>>>>> 1. Cluster-DRC is one feature in getting ganesha in clustered
> >>>>>>>> mode completely failproof - at least, that was the original
> >>>>>>>> intent behind this feature. But in subsequent discussions in
> >>>>>>>> the ganesha community it was not deemed to be a must-have
> >>>>>>>> feature to get clustered-mode ganesha working as per current
> >>>>>>>> requirements. This consideration was to an extent, based on the
> >>>>>>>> fact that no data loss or catastrophic incidents have been
> >>>>>>>> reported in the community due to lack of cluster-drc.
> >>>>>>>
> >>>>>>> Thanks for the clarification. Without DRC implementation, does
> >>>>>>> it implies that, NFS v4 server state will not be maintained
> >>>>>>> during failover? Such as file locking state etc.
> >>>>>>> Just trying to figure out, 

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

> Frank, thanks for your reply, really help me to understand how the NFS HA
> works.
> 
> Another question coming into my mind is:
> The "state reclaim" only talks about reclaim locks, what about the reply
> cache, which is used to implement exactly-once-semantics?
> Previous email states that nfs-ganesha will not implement distributed reply
> cache(DRC), thus the exactly-once-semantics will not be maintained during
> failover?

Correct. It's impossible to guarantee anyway, unless you make the DRC 
transactional with the operations.

Consider this:

Client sends a REMOVE to delete a file
Server processes the unlink system call, but fails before response is saved in 
clustered DRC and thus before response is sent to client
Client retries REMOVE, which is not detected by DRC and thus an unlink system 
call is made that fails

Only way to make that perfect is to make DRC atomic with the unlink system 
call...

Frank

> On Wed, May 27, 2015 at 4:05 PM, Frank Filz 
> wrote:
> >> On Tue, May 26, 2015 at 5:04 PM, edison su  wrote:
> >> > Could you elaborate the "server failure mechanism build into NFS"?
> >> > Without sharing state with other node, how the failover can happen
> >> > correctly? I know, in NFSv2 and V3, for the stateless NFS server,
> >> > the failover should be easy. But in NFSv4, there are lot of states
> >> > are maintained by NFS server, for proper failover, these states
> >> > needed to be saved in somewhere.
> >>
> >> Does the "server failure mechanism build into NFS" mean something
> >> like state reclaim specified in NFSV4.1 8.4.2.1?
> >
> > Yes.
> >
> > Frank
> >
> >> >
> >> >
> >> > On Tue, May 26, 2015 at 4:50 PM, Frank Filz
> >> > 
> >> wrote:
> >> >> I think that's just documenting the support Gluster has to allow
> >> >> multiple
> >> node cluster of Ganesha so state is reflected across all the cluster
> >> nodes. But to accomplish a failover Ganesha itself either has to
> >> share all the gory details of state or it has to rely on the server failure
> mechanism built into NFS.
> >> >>
> >> >> Frank
> >> >>
> >> >> Sent from my iPhone
> >> >>
> >> >> On May 26, 2015, at 4:09 PM, edison su  wrote:
> >> >>
> >> >>> Hmm, interesting. Gluster's
> >> >>>
> >>
> doc(http://www.gluster.org/community/documentation/index.php/Feature
> >> >>> s/Upcall-infrastructure),
> >> >>> it does maintain
> >> >>> lock and file delegation state. Do I read the doc wrong?
> >> >>>
> >> >>> On Tue, May 26, 2015 at 3:34 PM, Frank Filz
> >> >>> 
> >> wrote:
> >> >>>> None of these state items are preserved in failover. Ganesha
> >> exclusively relies on state recovery to migrate state to failover node.
> >> >>>>
> >> >>>> Frank
> >> >>>>
> >> >>>> Sent from my iPhone
> >> >>>>
> >> >>>> On May 26, 2015, at 3:17 PM, edison su 
> wrote:
> >> >>>>
> >> >>>>> On Tue, May 26, 2015 at 3:35 AM, Anand Subramanian
> >>  wrote:
> >> >>>>>> On 05/22/2015 10:42 PM, edison su wrote:
> >> >>>>>>>
> >> >>>>>>> On Thu, May 21, 2015 at 11:59 PM, Anand Subramanian
> >> >>>>>>> 
> >> >>>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>> On 05/22/2015 04:27 AM, edison su wrote:
> >> >>>>>>>>>
> >> >>>>>>>>> Hi all,
> >> >>>>>>>>> I am following the doc @
> >> >>>>>>>>> https://github.com/nfs-ganesha/nfs-ganesha/wiki/Cluster-
> DRC
> >> >>>>>>>>> , but can't figure out how to setup a cluster ganesha.
> >> >>>>>>>>> Is the feature already implemented yet, or still in the
> >> development?
> >> >>>>>>>>> If it's implemented already, is there any document about
> >> >>>>>>>>> how to setup it up?
> >> >>>>>>>>> I am using Gluster as FSAL, I looked at
> >> >>>>>>>

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

> On Wed, May 27, 2015 at 9:30 PM, Frank Filz 
> wrote:
> >> Frank, thanks for your reply, really help me to understand how the
> >> NFS HA works.
> >>
> >> Another question coming into my mind is:
> >> The "state reclaim" only talks about reclaim locks, what about the
> >> reply cache, which is used to implement exactly-once-semantics?
> >> Previous email states that nfs-ganesha will not implement distributed
> >> reply cache(DRC), thus the exactly-once-semantics will not be
> >> maintained during failover?
> >
> > Correct. It's impossible to guarantee anyway, unless you make the DRC
> transactional with the operations.
> >
> > Consider this:
> >
> > Client sends a REMOVE to delete a file Server processes the unlink
> > system call, but fails before response is saved in clustered DRC and
> > thus before response is sent to client Client retries REMOVE, which is
> > not detected by DRC and thus an unlink system call is made that fails
> >
> > Only way to make that perfect is to make DRC atomic with the unlink
> system call...
> 
> Maybe something like transaction log/journal can help here:
> before calling unlink system call, nfs server should persistent a log to
> somewhere saying that server is calling unlink system call with certain
> parameters.
> If unlink system call succeed, then add another transaction log saying this
> operation succeed.
> If unlink failed, then add another transaction log saying this operation 
> failed.
> In any case, if server is crashed, then another nfs server can check the
> transaction log to find out what exactly happened for this request.

That would help, though we would still be left guessing if we find:

An entry in the transaction log indicating an unlink call is to be made
The file is deleted

The file may or may not have actually been deleted by the unlink call in the 
transaction log

UNLESS we don't expect any other process to be deleting files (either every 
process uses the same transaction log, or Ganesha is the only process touching 
the files).

But if we have every process using the same transaction log, then we basically 
get back to my statement of being able to make the DRC and unlink atomic.

Frank

> > Frank
> >
> >> On Wed, May 27, 2015 at 4:05 PM, Frank Filz 
> >> wrote:
> >> >> On Tue, May 26, 2015 at 5:04 PM, edison su 
> wrote:
> >> >> > Could you elaborate the "server failure mechanism build into NFS"?
> >> >> > Without sharing state with other node, how the failover can
> >> >> > happen correctly? I know, in NFSv2 and V3, for the stateless NFS
> >> >> > server, the failover should be easy. But in NFSv4, there are lot
> >> >> > of states are maintained by NFS server, for proper failover,
> >> >> > these states needed to be saved in somewhere.
> >> >>
> >> >> Does the "server failure mechanism build into NFS" mean something
> >> >> like state reclaim specified in NFSV4.1 8.4.2.1?
> >> >
> >> > Yes.
> >> >
> >> > Frank
> >> >
> >> >> >
> >> >> >
> >> >> > On Tue, May 26, 2015 at 4:50 PM, Frank Filz
> >> >> > 
> >> >> wrote:
> >> >> >> I think that's just documenting the support Gluster has to
> >> >> >> allow multiple
> >> >> node cluster of Ganesha so state is reflected across all the
> >> >> cluster nodes. But to accomplish a failover Ganesha itself either
> >> >> has to share all the gory details of state or it has to rely on
> >> >> the server failure
> >> mechanism built into NFS.
> >> >> >>
> >> >> >> Frank
> >> >> >>
> >> >> >> Sent from my iPhone
> >> >> >>
> >> >> >> On May 26, 2015, at 4:09 PM, edison su 
> wrote:
> >> >> >>
> >> >> >>> Hmm, interesting. Gluster's
> >> >> >>>
> >> >>
> >>
> doc(http://www.gluster.org/community/documentation/index.php/Feature
> >> >> >>> s/Upcall-infrastructure),
> >> >> >>> it does maintain
> >> >> >>> lock and file delegation state. Do I read the doc wrong?
> >> >> >>>
> >> >> >>> On Tue, May 26, 2015 at 3:34 PM, Frank Filz
> >> >> >>> 
> >> 

[Nfs-ganesha-devel] Upcoming patch set to replace attrlist in fsal_obj_handle with pointer

[Frank Filz]

Folks,

I would like to get all FSALs prepared with this before actually pushing
this in.

Please help and update your FSAL.

You can base on this branch:

https://github.com/ffilz/nfs-ganesha/commits/attr-ptr

Once we have all FSALs converted, we can add a final patch that takes out
the temporary workaround code.

FSALs we need conversion of:

FSAL_CEPH
FSAL_GLUSTER
FSAL_GPFS
FSAL_HPSS
FSAL_LUSTRE
FSAL_PROXY
FSAL_PT
FSAL_ZFS

Completed:

FSAL_PSEUDO
FSAL_VFS
Stackable_FSALs/FSAL_NULL

Thanks

Frank




--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

> I see, so the reply cache will be regarded as "best effort".
> What about the status of "state reclaim " in nfs-ganesha? The doc:
> https://github.com/phdeniel/nfs-ganesha/wiki/Ganesha-and-NFSv4.0-
> 4.1#Grace_Period_Recovery_and_Reclaim_Rules,
> seems a little bit too old.
> Is nfs-ganesha "state reclaim" implementation fully compatible with
> NFSv4.1?

Hmm, I have no idea how well that wiki correlates to the actual code...

We need someone to really own maintaining the wiki documentation...

I THINK NFS v4.1 reclaim is complete, but there's probably some holes... 
Unfortunately, no one has been really invested in making sure Ganesha's NFS 
v4.1 implementation is actually complete.

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

> From: J. Bruce Fields [mailto:bfie...@fieldses.org]
> On Wed, May 27, 2015 at 10:10:26PM -0700, Frank Filz wrote:
> > UNLESS we don't expect any other process to be deleting files (either
> > every process uses the same transaction log, or Ganesha is the only
> > process touching the files).
> >
> > But if we have every process using the same transaction log, then we
> > basically get back to my statement of being able to make the DRC and
> > unlink atomic.
> 
> Most filesystems already do this kind of thing somewhere under the covers,
> so in theory it should be possible to solve this in cooperation with the
> filesystem, but nobody's looked into it seriously that I'm aware of.
> 
> The same problem can happen over a crash/restart.
> 
> One useful step might be to work out how to reproduce the problem easily
> and reliably.

Yea, if the filesystems provided an interface to hook into their transaction
log, we could implement this pretty easily.

The catch might be in how the filesystem would want to handle transaction
recovery when a user space application initiated a transaction. There would
have to be some mechanism to abort the user space transaction if it was
unable to perform it's recovery, with a definition of what happens to the
filesystem portions of that transaction (does the unlink take effect
yes/no?).

Frank



--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Upcoming patch set to replace attrlist in fsal_obj_handle with pointer

[Frank Filz]

> patch URL with changes needed in FSAL_GLUSTER  -
> 
> https://github.com/soumyakoduri/nfs-
> ganesha/commit/920dac38464e975472eaa1771b02d58a01980f9a

Vincent,

Could you pull this patch into your branch?

Thanks

Frank

> On 05/28/2015 10:54 PM, Frank Filz wrote:
> > Folks,
> >
> > I would like to get all FSALs prepared with this before actually
> > pushing this in.
> >
> > Please help and update your FSAL.
> >
> > You can base on this branch:
> >
> > https://github.com/ffilz/nfs-ganesha/commits/attr-ptr
> >
> > Once we have all FSALs converted, we can add a final patch that takes
> > out the temporary workaround code.
> >
> > FSALs we need conversion of:
> >
> > FSAL_CEPH
> > FSAL_GLUSTER
> > FSAL_GPFS
> > FSAL_HPSS
> > FSAL_LUSTRE
> > FSAL_PROXY
> > FSAL_PT
> > FSAL_ZFS
> >
> > Completed:
> >
> > FSAL_PSEUDO
> > FSAL_VFS
> > Stackable_FSALs/FSAL_NULL
> >
> > Thanks
> >
> > Frank
> >
> >
> >
> >
> > --
> >  ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-5

[Frank Filz]

Branch next

Tag:V2.3-dev-5

Highlights

* Update to checkpatch.conf

* GPFS config changes

* FSAL_GLUSTER support for conversion between POSIX ACL and NFS4 ACL

* FSAL_GLUSTER upcall interface

* FSAL_GLUSTER config options

* FSAL_GLUSTER pNFS performance enhancements

Signed-off-by: Frank S. Filz 

Contents:

b90dcff Dominique Martinet checkpatch.conf: ignore maintainer
warning/checkpatch in subject
cd439dc Malahal Naineni gpfs: disable delegations and increase cache inode
high water mark.
bc738c2 Jiffin Tony Thottan FSAL_GLUSTER : Introducing new api's in ds_write
and ds_read for performance improvement
e1ac1bb Anand Subramanian Fixing FSAL_GLUSTER NFSv3 crash in iozone test.
35ee9dd Jiffin Tony Thottan FSAL_GLUSTER : Conversion of nfs4 acls to posix
acls for directories
96564ae Jiffin Tony Thottan FSAL_GLUSTER : Conversion of nfs4 acls <-> posix
acls using standard libacl api's
e0a35a5 Meghana Madhusudhan FSAL_GLUSTER: Change the position of gfapi.log
da055e4 Jiffin Tony Thottan FSAL_GLUSTER : Parsing the global options
1cea9f7 Soumya Koduri FSAL_GLUSTER: Upcall interface to receive
notifications from the server.


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] What's the status of cluster ganesha?

[Frank Filz]

> On Thu, May 28, 2015 at 11:20:31AM -0700, Frank Filz wrote:
> > > From: J. Bruce Fields [mailto:bfie...@fieldses.org] On Wed, May 27,
> > > 2015 at 10:10:26PM -0700, Frank Filz wrote:
> > > > UNLESS we don't expect any other process to be deleting files
> > > > (either every process uses the same transaction log, or Ganesha is
> > > > the only process touching the files).
> > > >
> > > > But if we have every process using the same transaction log, then
> > > > we basically get back to my statement of being able to make the
> > > > DRC and unlink atomic.
> > >
> > > Most filesystems already do this kind of thing somewhere under the
> > > covers, so in theory it should be possible to solve this in
> > > cooperation with the filesystem, but nobody's looked into it seriously
> that I'm aware of.
> > >
> > > The same problem can happen over a crash/restart.
> > >
> > > One useful step might be to work out how to reproduce the problem
> > > easily and reliably.
> >
> > Yea, if the filesystems provided an interface to hook into their
> > transaction log, we could implement this pretty easily.
> >
> > The catch might be in how the filesystem would want to handle
> > transaction recovery when a user space application initiated a
> > transaction. There would have to be some mechanism to abort the user
> > space transaction if it was unable to perform it's recovery, with a
> > definition of what happens to the filesystem portions of that
> > transaction (does the unlink take effect yes/no?).
> 
> I don't understand the need for an abort mechanism?
> 
> You need some way to retry (or query the status of) some operation that
> was attempted before a restart, that's all.

I think I was thinking in a general sense. If the kernel provided hooks to
filesystem transactions, in a general case, there might be a need for abort.

NFS certainly would be fine without abort since if we started to process a
request, the client has no expectation the request would NOT be processed
even if the server failed to respond. So NFS would probably just make sure
the DRC was consistent and either the client retries and the response comes
from DRC or client doesn't care or gave up.

Oh, but thinking more, the kernel would need to make sure it doesn't fall in
a pit if the user space transaction recovery fails somehow. In that case, as
far as Ganesha is concerned, we probably would be fine with the kernel just
discarding the user space transaction and doing the filesystem transaction
recovery, so the unlink happens but the DRC get's lost. But that would only
be because of a bug in Ganesha, some system config failure which caused
Ganesha to not be restarted.

The key is the kernel isn't held hostage by a buggy or mis-configured user
space process.

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Configuring pNFS/spnfsd - Linux NFS

[Frank Filz]

Ganesha doesn’t support something like spnfsd, though it would be an
interesting project to implement spndsd using Ganesha.

 

Frank

 

From: 孙俊 [mailto:9524...@qq.com] 
Sent: Monday, June 1, 2015 12:36 AM
To: nfs-ganesha-devel
Subject: [Nfs-ganesha-devel] Configuring pNFS/spnfsd - Linux NFS

 

http://wiki.linux-nfs.org/wiki/index.php/Configuring_pNFS/spnfsd

 

can i use nfs-ganesha like spnfsd

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] No Con call Today

[Frank Filz]

With most of us that are active here in Ann Arbor, I don't see a reason to
interrupt our Bakeathon efforts to have the con call.

I will most likely be pulling for a merge tomorrow when I am at home, though
if I have time to pull today I may do so.

Thanks

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-6

[Frank Filz]

Branch next

Tag:V2.3-dev-6

Highlights

* 9p fixes

* cmake fixes

* Don't use CRED_WRAP in fsal_open for FSAL_LUSTRE

* Send SECINFO_NO_NAME in preferred order.

* Remove annoying LogMajor if NFS4ERR_WRONGSEC on LOOKUP

* Other minore fixes

Signed-off-by: Frank S. Filz 

Contents:

b039ab0 Frank S. Filz V2.3-dev-6
afb6638 Frank S. Filz Remove annoying LogMajor if NFS4ERR_WRONGSEC on LOOKUP
4f2ca5e Malahal Naineni Fix missing config file causing a segfault.
48c19b6 Malahal Naineni Fix typo in config.txt file.
f6fa32b Malahal Naineni Fix segmentation fault when full logging is enabled.
745fe76 Dominique Martinet NFSv4: Send SECINFO_NO_NAME in preferred order.
a3b3e8c Dominique Martinet CMake: set LIBTIRPC_LIBRARIES to ntirpc's
"ntirpc" target
8f52a63 Dominique Martinet CMake: fix jemalloc/tcmalloc overwritting
SYSTEM_LIBRARIES
1104d42 Dominique Martinet 9P: open after create corner cases do not belong
here
610d88f Dominique Martinet LUSTRE: open() should not use CRED_WRAP
65e3146 Dominique Martinet 9P: initialize our local lock variables
09ff093 Vincent Saulue-Laborde 9P : modify op_ctx initialization (worker
threads use different values)
e08dbba Vincent Saulue-Laborde 9P : Turn user credentials into a refcounted
object


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Gerrithub spam etc.

[Frank Filz]

Allison accidentally pushed a patch based on another project which has
resulted in a tremendous number of duplicate patches showing up on
gerrithub.

This is also resulting in huge amounts of spam e-mail to at least some
individuals (fortunately seems NOT to be going to the list).

In the meantime, until this clears up, I am considering gerrithub broken and
won't try to review things and such.

I hope this doesn't have a negative impact on next weeks build.

Thanks

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Upcoming patch set to replace attrlist in fsal_obj_handle with pointer

[Frank Filz]

I just completed FSAL_CEPH and then added the final patch to remove the
deprecated fsal_obj_handle attributes.

Please everyone review these patches so we can get them in this week.

Thanks

Frank

> > patch URL with changes needed in FSAL_GLUSTER  -
> >
> > https://github.com/soumyakoduri/nfs-
> > ganesha/commit/920dac38464e975472eaa1771b02d58a01980f9a
> 
> Vincent,
> 
> Could you pull this patch into your branch?
> 
> Thanks
> 
> Frank
> 
> > On 05/28/2015 10:54 PM, Frank Filz wrote:
> > > Folks,
> > >
> > > I would like to get all FSALs prepared with this before actually
> > > pushing this in.
> > >
> > > Please help and update your FSAL.
> > >
> > > You can base on this branch:
> > >
> > > https://github.com/ffilz/nfs-ganesha/commits/attr-ptr
> > >
> > > Once we have all FSALs converted, we can add a final patch that
> > > takes out the temporary workaround code.
> > >
> > > FSALs we need conversion of:
> > >
> > > FSAL_CEPH
> > > FSAL_GLUSTER
> > > FSAL_GPFS
> > > FSAL_HPSS
> > > FSAL_LUSTRE
> > > FSAL_PROXY
> > > FSAL_PT
> > > FSAL_ZFS
> > >
> > > Completed:
> > >
> > > FSAL_PSEUDO
> > > FSAL_VFS
> > > Stackable_FSALs/FSAL_NULL
> > >
> > > Thanks
> > >
> > > Frank
> > >
> > >
> > >
> > >
> > > 
> > > --
> > >  ___
> > > Nfs-ganesha-devel mailing list
> > > Nfs-ganesha-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> > >
> 
> 
>

--
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] fridge threads and worker latency

[Frank Filz]

> > so I'd appreciate it if you walk through your blocker with us here.
> >
> No blocker.  Or at least I hope not.  Currently (as in the code checked in
on
> my rdma-was branch), I'm trying to finesse
> thr_decode_rpc_request() by checking for the parameter, and calling
> nfs_rpc_execute() directly for RDMA (skipping the extra worker
> enqueue/dequeue).
> 
> But that only almost works.  nfs_rpc_execute() has a worker_data
> parameter, which is passed to every gol-darned nfs_proto function:
> 
> rc = reqnfs->funcdesc->service_function(arg_nfs,
>  worker_data, svcreq,
>  res_nfs);
> 
> I've already folded the worker_data into the fridge_entry, reducing the
> alloc/free cost (as they are one-to-one).
> 
> Since I have to fake this somehow, it seems to me a good time to simplify
the
> fridge itself.  After public discussion.
> 
> I'm hoping to eliminate the worker_data parameter entirely.
> 
> Or at least make it work for NULL.
> 
> It's impractical to copy and paste duplicate and re-write every nfs_proto
> function

Hmm, we could definitely clean this up, it would be good to actually remove
it and anything that is really necessary be thread local variables.

The worker_index could become a general thread index and be a thread local
variable (it really is useful for debug logging so please don't anyone get
any bright ideas about removing it...).

I'm sure there's a better way to handle the hostaddr part (there was also
some talk about client manager being a performance downer). We do need to
know the hostaddr across the stack for various reasons, but again, we should
find a cleaner way to handle it that copying it into worker_data.

The other fields in worker_data are specific to the fridge and queuing and
should be separated anyway probably, and hopefully you are cleaning up how
all that works...

We actually should move ALL the request params into req_ctx, it would make
for simpler function processing and it's much easier to add/remove params
that way.

Frank



--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] [Gluster-users] Questions on ganesha HA and shared storage size

[Frank Filz]

> 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 encapsulate IPv4 traffic. In my testing I use IPv4 addresses, but
they are encapsulated in IPv6 (and thus forced me to get Ganesha's support
for that to actually work...).

> > commit - git show 'd7e8f255' , which got added in v2.2 has more details.
> >
> >  > # netstat -ltaupn | grep 2049
> >  > tcp6   4  0 :::2049 :::*
> >  > LISTEN  32080/ganesha.nfsd
> >  > tcp6   1  0 x.x.x.2:2049  x.x.x.2:33285 CLOSE_WAIT
> >  > -
> >  > tcp6   1  0 127.0.0.1:2049  127.0.0.1:39555
> >  > CLOSE_WAIT  -
> >  > udp6   0  0 :::2049 :::*
> >  > 32080/ganesha.nfsd
> >  >
> >
> > >>> I have enabled the full debug already, but I see nothing special.
Before
> exporting any volume the log shows no error, even when I do a showmount
> (the log is attached, ganesha.log.gz). If I do the same after exporting a
> volume nfs-ganesha does not even start, complaining for not being able to
> bind the IPv6 ruota socket, but in fact there is nothing listening on
IPv6, so it
> should not happen:
> > >>>
> > >>> tcp6   0  0 :::111  :::*
LISTEN  7433/rpcbind
> > >>> tcp6   0  0 :::2224 :::*
LISTEN  9054/ruby
> > >>> tcp6   0  0 :::22   :::*
LISTEN  1248/sshd
> > >>> udp6   0  0 :::111  :::*
7433/rpcbind
> > >>> udp6   0  0 fe80::8c2:27ff:fef2:123 :::*
31238/ntpd
> > >>> udp6   0  0 fe80::230:48ff:fed2:123 :::*
31238/ntpd
> > >>> udp6   0  0 fe80::230:48ff:fed2:123 :::*
31238/ntpd
> > >>> udp6   0  0 fe80::230:48ff:fed2:123 :::*
31238/ntpd
> > >>> udp6   0  0 ::1:123 :::*
31238/ntpd
> > >>> udp6   0  0 fe80::5484:7aff:fef:123 :::*
31238/ntpd
> > >>> udp6   0  0 :::123  :::*
31238/ntpd
> > >>> udp6   0  0 :::824  :::*
7433/rpcbind
> > >>>
> > >>> The error, as shown in the attached ganesha-after-export.log.gz
> logfile, is the following:
> > >>>
> > >>>
> > >>> 10/06/2015 02:07:47 : epoch 55777fb5 : node2 :
> > >>> ganesha.nfsd-26195[main] Bind_sockets_V6 :DISP :WARN :Cannot
> bind
> > >>> RQUOTA tcp6 socket, error 98 (Address already in use)
> > >>> 10/06/2015 02:07:47 : epoch 55777fb5 : node2 : ganesha.nfsd-
> 26195[main] Bind_sockets :DISP :FATAL :Error binding to V6 interface.
Cannot
> continue.
> > >>> 10/06/2015 02:07:48 : epoch 55777fb5 : node2 :
> > >>> ganesha.nfsd-26195[main] glusterfs_unload :FSAL :DEBUG :FSAL
> > >>> Gluster unloaded
> > >>>
> 
> The above messages indicate that someone tried to restart ganesha. But
> ganesha failed to come up because RQUOTA port (default is 875) is already
in
> use by an old ganesha instance or some other program holding it. The new
> instance of ganesha will die, but if you are using systemd, it will try to
restart
> automatically. We have disabled systemd auto restart in our environment as
> it was causing issues for debugging.
> 
> What version of ganesha is this?
> 
> Regards, Malahal.
> 
> 
>

--
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-7

[Frank Filz]

Branch next

Tag:V2.3-dev-7

Highlights

* GLUSTER fixes (ACL, NULL pointer, upcalls)

* NFSv4.1 sequence: give a better guess at sr_target_highest_slotid

Signed-off-by: Frank S. Filz 

Contents:

b58a567 Frank S. Filz V2.3-dev-7
ab50343 Dominique Martinet NFSv4.1 sequence: give a better guess at
sr_target_highest_slotid
366f71c Soumya Koduri FSAL_GLUSTER: Fixed an issue with dereferencing a NULL
ponter
c4f33d6 Jiffin Tony Thottan FSAL_GLUSTER : Improvements in acl feature
b1df525 Soumya Koduri FSAL_GLUSTER: Stop polling upcall events if not
supported


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Ganesha crash on a rm

[Frank Filz]

> Hi Krishna, The code doesn't seem to match exactly with V2.1.0 but it does
> look like nfs3_remove() entered label "out_fail". Wondering what the
> cache_status was at the time of the crash.
> 
> There were some fixes in V2.2-stable related refcounting, but I am not
sure if
> V2.2-stable fixes your issues.
> 
> What FSAL are you using? Also, if you can reproduce this under valgrind,
that
> should give us more information to see if we are using the freed entry
itself
> here.
> 
> As I said, I don't see any commit in particular that fixes this issue but
V2.2-
> stable is the current release (and it is our long term release!)

I would like to see this recreated on V2.2.0 before doing too much digging.
Due to the significant stability issues addressed in V2.2.0, it's quite
possible that issues have been fixed without understanding exactly the
impact of various fixes.

Frank

> Krishna Harathi [khara...@exablox.com] wrote:
> >Using Ganesha version 2.1.0, NFSv3 exports and clients.
> >We are seeing the following crash where Ganesha is trying to access
> parent
> >inode to SetPostOpAttr() and ion the crash, we see that the parent
> >obj_handle is NULL.
> >Is this a known issue, and are there any recent fices in this area?
Any
> >help is
> >appreciated.
> >
> >  Thread 1 (LWP 6688):
> >  #0  0x0050ad94 in cache_inode_is_attrs_valid (entry=0x6b424500)
> >  at
> > /git/packaging/nfs-ganesha/nfs-ganesha/src/include/cache_inode.h:939
> >  #1  0x0050e5d8 in cache_inode_lock_trust_attrs (entry=0x6b424500,
> need_wr_lock=false)
> >  at
> > /git/packaging/nfs-ganesha/nfs-
> ganesha/src/cache_inode/cache_inode_mis
> > c.c:887
> >  #2  0x004a1e04 in cache_entry_to_nfs3_Fattr (entry=0x6b424500,
> Fattr=0x698092f0)
> >  at
> > /git/packaging/nfs-ganesha/nfs-
> ganesha/src/Protocols/NFS/nfs_proto_too
> > ls.c:3567
> >  #3  0x0049a940 in nfs_SetPostOpAttr (entry=0x6b424500,
> attr=0x698092e8)
> >  at
> > /git/packaging/nfs-ganesha/nfs-
> ganesha/src/Protocols/NFS/nfs_proto_too
> > ls.c:79
> >  #4  0x0049abc8 in nfs_SetWccData (before_attr=0x70ffdc00,
> entry=0x6b424500, wcc_data=0x698092c8)
> >  at
> > /git/packaging/nfs-ganesha/nfs-
> ganesha/src/Protocols/NFS/nfs_proto_too
> > ls.c:132
> >  #5  0x00466bbc in nfs3_remove (arg=0x5fc90358, worker=0x6f008140,
> req=0x5fc902e8, res=0x698092c0)
> >  at
> > /git/packaging/nfs-ganesha/nfs-
> ganesha/src/Protocols/NFS/nfs3_remove.c
> > :161
> >  #6  0x0045b340 in nfs_rpc_execute (req=0x5fc72d30,
> worker_data=0x6f008140)
> >  at
> > /git/packaging/nfs-ganesha/nfs-
> ganesha/src/MainNFSD/nfs_worker_thread.
> > c:1257
> >  #7  0x0045bfa8 in worker_run (ctx=0x76562f00)
> >  at
> > /git/packaging/nfs-ganesha/nfs-
> ganesha/src/MainNFSD/nfs_worker_thread.
> > c:1506
> >  #8  0x00542684 in fridgethr_start_routine (arg=0x76562f00)
> >  at
> > /git/packaging/nfs-ganesha/nfs-ganesha/src/support/fridgethr.c:562
> >  #9  0x76f47368 in start_thread () from
> > /lib/mips-linux-gnu/libpthread.so.0
> >  #10 0x76e9af18 in fcvt_r () from /lib/mips-linux-gnu/libc.so.6
> >  #11 0x in ?? ()
> >  (gdb) f 0
> >  #0  0x0050ad94 in cache_inode_is_attrs_valid (entry=0x6b424500)
> >  at /git/packaging/nfs-ganesha/nfs-
> ganesha/src/include/cache_inode.h:939
> >  939in /git/packaging/nfs-ganesha/nfs-
> ganesha/src/include/cache_inode.h
> >
> >  (gdb) p entry->obj_handle
> >  $1 = (struct fsal_obj_handle *) 0x0
> >
> >Regards.
> >Krishna Harathi
> 
> > --
> > 
> 
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> 
> 
>

--
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] NFS Ganesha and Caching

[Frank Filz]

I’m forwarding this to the nfs-ganesha-devel mailing list, since other folks 
may have thoughts also.

 

Ganesha only has a metadata and namespace (directory entries) cache, no data 
cache. The CACHE_INODE { Entries_HWMark }} option controls the maximum number 
of cache inode entries maintained. I don’t know if there is any limit on the 
number of directory entries stored.

 

Frank

 

From: Nilesh Joshi [mailto:josh...@gmail.com] 
Sent: Wednesday, June 17, 2015 12:50 PM
To: ffilz...@mindspring.com
Subject: NFS Ganesha and Caching

 

Hi Frank,

I am trying to figure out caching related settings in ganesha config file like 
cache size, 
Do you have any insight on how cache is configured in Ganesha.

In config file I could see CACHE_INODE, but my understanding is its a metadata 
cache.

I am using Ganesha 2.2, in CentOS 7 with VFS FSAL and underlying XFS file 
system.

Thanks,

Nilesh Joshi

 

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Gerrithub and editing - Please don't use

[Frank Filz]

Gerrithub has a feature to allow editing of patches. This seems like a nice
feature.

The problem is that it does not rebase any subsequent patches.

So when I merge by pulling a branch from your top patch, I DON'T get the
edited patches... Unless they ARE the top patch of a patch set (or only
patch).

This further re-inforces Gerrithub really wanting to treat patches as
individual independent entities.

Thanks

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Gerrithub and editing - Please don't use

[Frank Filz]

I had fixed the patch set up for you, but looks like you pushed again. Will 
take a look when I get down to my office. 

Frank

Sent from my iPhone

On Jun 19, 2015, at 6:49 AM, William Allen Simpson 
 wrote:

> On 6/19/15 9:25 AM, William Allen Simpson wrote:
>> On 6/18/15 6:07 PM, Frank Filz wrote:
>>> Gerrithub has a feature to allow editing of patches. This seems like a nice
>>> feature.
>>> 
>> Hey, I did ask yesterday!
>> 
>> 
>>> The problem is that it does not rebase any subsequent patches.
>>> 
>> How ridiculous.  In other words, not actually running git
>> 
> There's a rebase button.  Next time, I'll try that after an edit.
> 
> 
> 
>> 
>>> So when I merge by pulling a branch from your top patch, I DON'T get the
>>> edited patches... Unless they ARE the top patch of a patch set (or only
>>> patch).
>>> 
>> What do you want me to do?
>> 
>> I've got this huge flurry of useless messages with repetitive
>> content.  Is there an easy way for me to suck them down into a
>> new repository, fix them, and push them back up?
>> 
> I found the pull copy to clipboard, and made a new branch from next.
> 
> I'll try to make any needed changes and push them back up as a set.
> 

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Gerrithub and editing - Please don't use

[Frank Filz]

> On 6/19/15 9:25 AM, William Allen Simpson wrote:
> > On 6/18/15 6:07 PM, Frank Filz wrote:
> >> Gerrithub has a feature to allow editing of patches. This seems like
> >> a nice feature.
> >>
> > Hey, I did ask yesterday!

Yep, and naïve me at the time thought it would be ok. Then I had second 
thoughts and did an experiment...

> >> The problem is that it does not rebase any subsequent patches.
> >>
> > How ridiculous.  In other words, not actually running git
> >
> There's a rebase button.  Next time, I'll try that after an edit.

I think you would have to rebase every subsequent patch. At that point, it's 
probably easier to do everything in local git and do one of the following:

1. Make the correction at HEAD, use git rebase -i to push the change back to 
the original patch as a fixup

2. Use git rebase -i to edit the patch

3. Edit the patch in gerrithub, pull down a branch with HEAD at the edited 
patch, rebase the rest of your old branch on top of the edited patch

> >> So when I merge by pulling a branch from your top patch, I DON'T get
> >> the edited patches... Unless they ARE the top patch of a patch set
> >> (or only patch).
> >>
> > What do you want me to do?

I had fixed everything up and had it all merged and tested... But not sure that 
expediency was worth it...

I basically extracted your change and applied it using method 1 listed above...

> > I've got this huge flurry of useless messages with repetitive content.
> > Is there an easy way for me to suck them down into a new repository,
> > fix them, and push them back up?
> >
> I found the pull copy to clipboard, and made a new branch from next.
> 
> I'll try to make any needed changes and push them back up as a set.

Thanks

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Ganesha crash on a rm

[Frank Filz]

Could you submit your fix to gerrithub?

 

Thanks

 

Frank

 

From: Omkar Joshi [mailto:o...@hedviginc.com] 
Sent: Friday, June 19, 2015 11:50 AM
To: Krishna Harathi
Cc: nfs-ganesha-devel
Subject: Re: [Nfs-ganesha-devel] Ganesha crash on a rm

 

check cache inode related bug which I had raised on red hat bugzilla. It may be 
related to that... I have posted the fix for this.

 

On Thu, Jun 18, 2015 at 8:15 AM, Krishna Harathi mailto:khara...@exablox.com> > wrote:

Hi Malahal,

 

We are using VFS FSAL. 

 

In the original email, I noted that the parent cache entry in question is qid = 
LRU_ENTRY_CLEANUP, so I guess the cache entry is in the cleanup queue, whereas 
this thread in question is trying to access the entry to fill up some post-op 
attributes in the NFS reply. 

 

The workload is "rm -rf" of 1000K files that runs for couple of days, with 
other IO in parallel, it does not crash always and it is hard to re-create.  My 
guess of what is happening here is - a file is getting removed 

 

Also, we cannot pick up Ganesha 2.2 because of our release cycles, it is in the 
plan, it came out only recently. 

Having said that,  the crash you see is with Ganesha 2.1.0 + refcount and other 
patches from 2.2.0.  As you said, I also suspect 2.2 may not fix this issue, 

 

I just need help in debugging, my question is - when a directory entry is 
getting removed, at the time of filling up the postOp attributes from the 
parent Directory cache entry, what lock is supposed to be held on the parent 
entry? Also, the remove operation has returned with error from the VFS FSAL.

 

valgrind does not show any use-after-free errors or any other significant 
errors, only a bunch of allocated-but-not-freed memory at the end on normal 
exit, and that is usual for Ganehsa I guess?

 

Regards.

Krishna Harathi

 

On Wed, Jun 17, 2015 at 6:36 AM, Malahal Naineni mailto:mala...@us.ibm.com> > wrote:

Hi Krishna, The code doesn't seem to match exactly with V2.1.0 but it
does look like nfs3_remove() entered label "out_fail". Wondering what
the cache_status was at the time of the crash.

There were some fixes in V2.2-stable related refcounting, but I am not
sure if V2.2-stable fixes your issues.

What FSAL are you using? Also, if you can reproduce this under valgrind,
that should give us more information to see if we are using the freed
entry itself here.

As I said, I don't see any commit in particular that fixes this issue but
V2.2-stable is the current release (and it is our long term release!)

Regards, Malahal.


Krishna Harathi [khara...@exablox.com  ] wrote:
>Using Ganesha version 2.1.0, NFSv3 exports and clients.
>We are seeing the following crash where Ganesha is trying to access parent
>inode to SetPostOpAttr() and ion the crash, we see that the parent
>obj_handle is NULL.
>Is this a known issue, and are there any recent fices in this area? Any
>help is
>appreciated.
>
>  Thread 1 (LWP 6688):
>  #0  0x0050ad94 in cache_inode_is_attrs_valid (entry=0x6b424500)
>  at /git/packaging/nfs-ganesha/nfs-ganesha/src/include/cache_inode.h:939
>  #1  0x0050e5d8 in cache_inode_lock_trust_attrs (entry=0x6b424500, 
> need_wr_lock=false)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/cache_inode/cache_inode_misc.c:887
>  #2  0x004a1e04 in cache_entry_to_nfs3_Fattr (entry=0x6b424500, 
> Fattr=0x698092f0)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/Protocols/NFS/nfs_proto_tools.c:3567
>  #3  0x0049a940 in nfs_SetPostOpAttr (entry=0x6b424500, attr=0x698092e8)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/Protocols/NFS/nfs_proto_tools.c:79
>  #4  0x0049abc8 in nfs_SetWccData (before_attr=0x70ffdc00, entry=0x6b424500, 
> wcc_data=0x698092c8)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/Protocols/NFS/nfs_proto_tools.c:132
>  #5  0x00466bbc in nfs3_remove (arg=0x5fc90358, worker=0x6f008140, 
> req=0x5fc902e8, res=0x698092c0)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/Protocols/NFS/nfs3_remove.c:161
>  #6  0x0045b340 in nfs_rpc_execute (req=0x5fc72d30, worker_data=0x6f008140)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1257
>  #7  0x0045bfa8 in worker_run (ctx=0x76562f00)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1506
>  #8  0x00542684 in fridgethr_start_routine (arg=0x76562f00)
>  at /git/packaging/nfs-ganesha/nfs-ganesha/src/support/fridgethr.c:562
>  #9  0x76f47368 in start_thread () from /lib/mips-linux-gnu/libpthread.so.0
>  #10 0x76e9af18 in fcvt_r () from /lib/mips-linux-gnu/libc.so.6
>  #11 0x in ?? ()
>  (gdb) f 0
>  #0  0x0050ad94 in cache_inode_is_attrs_valid (entry=0x6b424500)
>  at /git/packaging/nfs-ganesha/nfs-ganesha/src/include/cache_inode.h:939
>  939in /git/packaging/nfs-ganesha/nfs-ganesha/src/include/cache_inode.h
>
>  (gdb) p entry->obj_handle
>  $1 = (struct fsal_obj_handle *) 0x0
>
>Regards.

[Nfs-ganesha-devel] Announce Push of V2.3-dev-8

[Frank Filz]

Branch next

Tag:V2.3-dev-8

Highlights

* Replace attributes member of fsal_obj_handle with attrs pointer
  Each private obj_handle will have an attributes member except for
  stackable FSALs which will just point to the underlying FSAL's
  private attributes member.

* Fix spurious valgrind errors in FSAL_GPFS

* 9P cleanup

* Make Debug build type use same strict compile options as Maintainer

* Make everything build config build all FSALs and remove obsolete IPv6
option

Signed-off-by: Frank S. Filz 

Contents:

7c9e4fd Frank S. Filz V2.3-dev-8
d34d599 Frank S. Filz Turn on all FSALs in everything.cmake and remove
obsolete USE_TIRPC_IPV6
dcb2846 Dominique Martinet CMake: make Debug strict compile
22ae181 Malahal Naineni Suppress spurious valgrind errors
38845bc Dominique Martinet Error handling: handle FSAL's ENODATA (xattr)
754f4a7 Dominique Martinet 9P/xattrwalk: pass errno directly from the FSAL
value
b310f41 Dominique Martinet VFS/xattrs: add symlink handling to
getextattr_id_by_name
0e21198 Dominique Martinet 9P/RDMA: init opctx in cleanup_fids
18bb84c Dominique Martinet 9P: statfs: replace NFS magic type by 9P's
d9ef256 Frank S. Filz Remove struct attrlist from fsal_obj_handle
c65d00b Soumya Koduri GLUSTER : Stop using the deprecated
fsal_obj_handle.attributes field.
c49609b Frank S. Filz CEPH : Stop using the deprecated
fsal_obj_handle.attributes field.
9c451f7 Vincent Saulue-Laborde Fsal_ZFS : Stop using the deprecated
fsal_obj_handle.attributes field.
d9d90f3 Vincent Saulue-Laborde Fsal_PT : Stop using the deprecated
fsal_obj_handle.attributes field.
e0f7dbf Vincent Saulue-Laborde Fsal_GPFS : Stop using the deprecated
fsal_obj_handle.attributes field.
d969cea Vincent Saulue-Laborde Fsal_Lustre : Stop using the deprecated
fsal_obj_handle.attributes field.
53f5fa3 Vincent Saulue-Laborde Fsal_Proxy : Stop using the deprecated
fsal_obj_handle.attributes field.
1017168 Vincent Saulue-Laborde PseudoFS : Stop using the deprecated
fsal_obj_handle.attributes field.
d553978 Vincent Saulue-Laborde VFS : Stop using the deprecated
fsal_obj_handle.attributes field.
ea0d8bb Vincent Saulue-Laborde NULLFS : use attrs field of fsal_obj_handle
instead of attributes
9f7096a Vincent Saulue-Laborde SAL : use attrs field of fsal_obj_handle
instead of attributes
519459c Vincent Saulue-Laborde Fsal common : use attrs field of
fsal_obj_handle instead of attributes
9ffa158 Vincent Saulue-Laborde NFS server : use attrs field of
fsal_obj_handle instead of attributes
fb4cb6c Vincent Saulue-Laborde 9P server : use attrs field of
fsal_obj_handle instead of attributes
7632ca5 Vincent Saulue-Laborde Cache inode : use attrs field of
fsal_obj_handle instead of attributes
98bffbb Vincent Saulue-Laborde Fsal_obj_handle : adding a pointer to
attributes.


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Bind_addr in nfs-ganesha - "Multiple addresses for..."

[Frank Filz]

It's been a while since I worked on that part of the code.

 

I'm not quite sure why the config parsing was changed from using inet_pton
to getaddrinfo, probably to be more flexible with what form the option
string can take.

 

It really should just take the first result, or look for the SOCK_STREAM
result (but the address that it is copying should be the same for all
anyway).

 

I think you could just patch the code to ignore the extra formats and not
break anything.

 

I've responded including the nfs-ganesha-devel list which is the best place
to get help with Ganesha since all the developers hang out there.

 

Frank

 

 

 

From: Glen Taylor [mailto:gtay...@thegeneral.com] 
Sent: Monday, June 22, 2015 10:08 AM
To: 'ffilz...@mindspring.com'
Subject: Bind_addr in nfs-ganesha - "Multiple addresses for..."

 

As best I can tell, you introduced the original feature allowing nfs-ganesha
to bind to a specific IPv4 address (NFS_CORE_PARAM->Bind_addr).  I was
thrilled to find this option (rather than firewalling IPs I didn't want),
but I have been unable to get this to work on any system because it always
fails with the config error "Multiple addresses found for [IP_ADDR]".  This
validation check is in config_parsing.c here:

 

https://github.com/nfs-ganesha/nfs-ganesha/blob/master/src/config_parsing/co
nfig_parsing.c#L591

 

I get the same result even if I specify the default value of "0.0.0.0" for
that parm.  I'm not set up to debug this in C, but when I call Python
 's
"getaddrinfo()" with the desired IP addr it gets 4 results, but they all
have the same IP/port combination:

 

[root@pgclnxvhost01 yum.repos.d]# python

Python 2.7.5 (default, Feb 11 2014, 07:46:25)

>>> import socket

>>> socket.getaddrinfo('192.168.42.203', 'nfs')

[(2, 1, 6, '', ('192.168.42.203', 2049)), (2, 2, 17, '', ('192.168.42.203',
2049)), (2, 1, 132, '', ('192.168.42.203', 2049)), (2, 5, 132, '',
('192.168.42.203', 2049))]

 

 

The differences seem to be things like datagram vs. stream, etc.  Does this
check perhaps need to be augmented to allow this to pass if all the
getaddrinfo() results are the same IP address that it'll proceed without
error?  Or is there some other way to work around this check?

 

Thanks in advance, and my apologies if you're the wrong person to ask this
of.

 

Glen Tayor

Web Systems Architect

The General Insurance

gtay...@thegeneral.com  

 

 

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Gerrithub and editing - Please don't use

[Frank Filz]

> William Allen Simpson wrote on Mon, Jun 22, 2015 at 03:26:38PM -0400:
> > Moreover, requiring library changes adds more variability to the mix.
> > The only patch that matters (to me) is the final patch.
> 
> I'd agree if we squash them after review, but since we don't, anyone
> bisecting do care about all the individual commits.
> 
> This has nothing to do with gerrit but with any workflow, I know kernel
> maintainers do build with all individual patches one at a time (Anna has a
> script that does for NFS)
> 
> > >Anyway, I'm sorry your patches didn't get in last week, there's a
> > >trivial conflict on rebase to new tip in "Remove unused
> > >nfs_worker_data parameters" -- I fixed it in my github's next.
> >
> > Especially as I'd been able to shuffle the errant "->" to "."
> > change into the correct patch.  Oh well, another time.
> >
> > Please only post changes tracking the post you want to fix, as there
> > doesn't seem to be a diff from mine to yours.
> 
> Attached it. I wanted to include it in my first mail but it was too big to 
> send
> inline along with another mail.
> 
> > Moreover, it's best not to squash patches from multiple sources.
> > If you have a patch to a patch, just add it to the chain.

It is common accepted practice in kernel land for maintainers to add stuff to 
patches, see the documentation:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/SubmittingPatches?id=refs/tags/v2.6.34.14#n334

And here’s an example of a patch by yours truly with such an update:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3fa0b4e201d254b52a251fa348bd53e53000cff6

Really such content could come from anyone as long as signed-off-by 
acknowledges their contribution.

> I can't, because then would have one commit that does not build (again).
> Please re-apply my patch yourself if you care - it comes straight out of a git
> diff of both branches (my next and your gerrithub tip)

And now that we have automatons running tests on every patch (which is a good 
thing) it is easier and more important to assure that each passes whatever 
tests the automatons run (even if it's just a compile). Will it mean perfect 
bisectability? No, but it will mean that folks WILL have an easier time doing a 
bisect if they need to.

Frank



--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] 'clustered' configuration parameter + use of nodeid

[Frank Filz]

> As we were discussing over #ganesha, currently 'clustered' mode mandates
> that each of the NFS-Ganesha servers is associated with a nodeid which may
> not be applicable for all the clustering solutions. We may choose to use
> IP_ADDR or hostnames to store persistent state information for each of the
> nodes in the cluster, which would then require this option to be turned off.
> 
> There could be cases where FSAL may like to know if its operating in
> 'clustered' mode for any special handling (if needed). This cannot be
> achieved by using existing 'clustered' option (if not using nodeids).
> 
> So we would like to know if we can de-couple 'clustered' option with the
> usage of nodeids and have different option if required to use nodeids.
> 
> Please share your thoughts.

I definitely agree that the "clustered" option is misnamed.

Further, from my investigation, which is not complete, it looks like a pure IP 
based clustering solution will not currently work with EVENT_TAKEIP for NFS v4.

For NFS v4, we persist information about each client-id so that we can 
determine if a client attempting to reclaim state has the right to do so, in 
particular, that it has not run afoul of the edge conditions documented in 
Section 9.6.3.4 of RFC 7530.

The code appears to look for a directory 
NFS_V4_RECOV_ROOT/gsp->ipaddr/NFS_V4_RECOV_DIR when it receives an 
EVENT_TAKEIP. But from what I can see, no other code creates or puts anything 
in such a directory. Instead, it seems that clientid information is only 
persisted in a directory: NFS_V4_RECOV_ROOT/NFS_V4_RECOV_DIR/nodeid, which is 
what is searched for EVENT_TAKE_NODE.

From talking with Malahal on IRC, I think the intent of EVENT_TAKE_NODE is that 
it is broadcast to all nodes that receive an IP address from another node, 
rather than sending an EVENT_TAKE_IP for each IP address that is moved. That 
may save some messages, but it's unclear that there aren’t some pitfalls. We 
would expect the only clients that would attempt reclaim would be those that 
actually moved (so a node that got an EVENT_RELEASE_IP to failback an IP 
address would dump the state for those clients associated with that IP address, 
and the node that we failed back to would get the EVENT_TAKE_NODE). But what 
conditions do we remove entries from the directory? In the case of the 
failback, we should only remove the entries belonging to the failed back IP 
address, the node will have other entries in that directory for the IP 
addresses that it retains.

Because of this, it would seem clearer to me if we only had EVENT_TAKE_IP, and 
that clientid persistent information was retained per IP address.

I think now is the time to make sure that Ganesha's clustering infrastructure 
is flexible and meets multiple implementation needs.

Note that the way Ganesha handles the epoch for clientids is structured in a 
way that Ganesha doesn't have to be party to the details. There is a command 
line option that allows and external actor (presumably the startup script) to 
pass Ganesha a unique clientid epoch for each instance. This epoch should 
include some kind of node identifier for a cluster, and some kind of time 
element (either a timestamp or a counter that is incremented each time Ganesha 
starts on the node) so that each time Ganesha is started on a given node, a new 
epoch is assigned. A cluster global atomic counter would also work that would 
issue a new unique epoch to any Ganesha instance in the cluster. The epoch is 
32 bits.

Frank


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] No build next week, may cancel concall

[Frank Filz]

Just after signing off, I remembered that we have company holiday next week
Thursday and Friday, so there won't be a build next week.

And maybe not a concall.

Frank



--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-9

[Frank Filz]

Branch next

Tag:V2.3-dev-9

Highlights

* Add ACL support to FSAL_PANFS

* Add optional non-persistent ACL memory store to FSAL_VFS to allow
  ACL testing and debugging

* Add optional increased RFC 7530 compliance for ACLs

* Bring FSAL_HPSS in tree

* Fix an uninitialized memory issue in nsm_mon

* Teach Valgrind about GPFS IOCTLs

* Some cmake changes

* Don't complain a

Signed-off-by: Frank S. Filz 

Contents:

bc5b848 Frank S. Filz V2.3-dev-9
00afd96 Malahal Naineni Teach valgrind about GPFS fsal ioctls.
b46b949 Malahal Naineni Initialize nsm_mon to avoid using unintialized data
cde75ea Dominique Martinet FSAL_HPSS: brings FSAL back from its ashes.
0f0909e Dominique Martinet CMake: fix SHOOK build with prefix/lustre v2.4+
515d2ec Dominique Martinet CMake: fix condition for proxy handle mapping
fccc3e3 Daniel Gryniewicz Add FSAL helpers for rename access checking
100fdd3 Daniel Gryniewicz ACL debugging - print ACLs in a compact format
8db82bf Daniel Gryniewicz Use NFS4ERR_ACCESS for ACL failures, not
NFS4ERR_PERM
1dab380 Daniel Gryniewicz FSAL - helper for mode/ACL interactions
43588b1 Daniel Gryniewicz ACL remove permissions
edb220c Daniel Gryniewicz FSAL helpers to implement ACL inheritence
990b360 Daniel Gryniewicz Some cleanup on FSAL_ACE flags/macros
e00e05f Daniel Gryniewicz Optionally check for READ_ATTR permission
a9c0b52 Daniel Gryniewicz Fix typo in attribute conversion
3e803d2 Daniel Gryniewicz FSAL_VFS - set attributes on create
2bbf224 Daniel Gryniewicz Allow forcing of ACL access check
1ce73c7 Daniel Gryniewicz export nfs4_acl_alloc() and nfs4_acl_free()
6dd8f6f Daniel Gryniewicz Add permission checks to FSAL_VFS create calls
f3b6994 Daniel Gryniewicz NFSv4 - Return error for unknown ACL type
7fcde6f Daniel Gryniewicz Testing - Add VFS ACL memstore
420bbb8 Daniel Gryniewicz ACL support for FSAL PanFS
3bc5a44 Daniel Gryniewicz Add FSAL sub_ops to FSAL_VFS
6612cf9 Daniel Gryniewicz Allow VFS Sub-FSALs to wrap object handles
24a35c3 Frank S. Filz Ignore warning about commit id


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Bill's patch set

[Frank Filz]

I ran into a problem with Bill's patch set where it immediately crashed
while running pynfs 4.1.

I'm not sure if it was an issue with the rebase I did or what.

Originally I was not planning on doing a merge next week. If we can get
Bill's patch set rebased onto V2.3-dev-9 and passing all tests by Wednesday,
I will cut a merge with JUST Bill's patches.

Thanks

Frank



--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Ganesha crash on a rm

[Frank Filz]

Did we ever get a fix for this submitted to gerrithub? That is the primary way 
we take fixes for current Ganesha development (V2.3). Issues for previous 
releases should be fixed in current next first or at least be submitted first 
before being submitted for previous releases.

 

Thanks

 

Frank

 

From: Krishna Harathi [mailto:khara...@exablox.com] 
Sent: Monday, June 29, 2015 9:31 AM
To: Omkar Joshi
Cc: nfs-ganesha-devel
Subject: Re: [Nfs-ganesha-devel] Ganesha crash on a rm

 

Ok, found your fix - https://bugzilla.redhat.com/show_bug.cgi?id=1218422

 

I will test your fix with the test-cases we have.




Regards.

Krishna Harathi

 

On Fri, Jun 19, 2015 at 3:32 PM, Krishna Harathi mailto:khara...@exablox.com> > wrote:

I will certainly pick up the fix and try it asap, thanks for pointing it out.




Regards.

Krishna Harathi

 

On Fri, Jun 19, 2015 at 11:50 AM, Omkar Joshi mailto:o...@hedviginc.com> > wrote:

check cache inode related bug which I had raised on red hat bugzilla. It may be 
related to that... I have posted the fix for this.

 

On Thu, Jun 18, 2015 at 8:15 AM, Krishna Harathi mailto:khara...@exablox.com> > wrote:

Hi Malahal,

 

We are using VFS FSAL. 

 

In the original email, I noted that the parent cache entry in question is qid = 
LRU_ENTRY_CLEANUP, so I guess the cache entry is in the cleanup queue, whereas 
this thread in question is trying to access the entry to fill up some post-op 
attributes in the NFS reply. 

 

The workload is "rm -rf" of 1000K files that runs for couple of days, with 
other IO in parallel, it does not crash always and it is hard to re-create.  My 
guess of what is happening here is - a file is getting removed 

 

Also, we cannot pick up Ganesha 2.2 because of our release cycles, it is in the 
plan, it came out only recently. 

Having said that,  the crash you see is with Ganesha 2.1.0 + refcount and other 
patches from 2.2.0.  As you said, I also suspect 2.2 may not fix this issue, 

 

I just need help in debugging, my question is - when a directory entry is 
getting removed, at the time of filling up the postOp attributes from the 
parent Directory cache entry, what lock is supposed to be held on the parent 
entry? Also, the remove operation has returned with error from the VFS FSAL.

 

valgrind does not show any use-after-free errors or any other significant 
errors, only a bunch of allocated-but-not-freed memory at the end on normal 
exit, and that is usual for Ganehsa I guess?

 

Regards.

Krishna Harathi

 

On Wed, Jun 17, 2015 at 6:36 AM, Malahal Naineni mailto:mala...@us.ibm.com> > wrote:

Hi Krishna, The code doesn't seem to match exactly with V2.1.0 but it
does look like nfs3_remove() entered label "out_fail". Wondering what
the cache_status was at the time of the crash.

There were some fixes in V2.2-stable related refcounting, but I am not
sure if V2.2-stable fixes your issues.

What FSAL are you using? Also, if you can reproduce this under valgrind,
that should give us more information to see if we are using the freed
entry itself here.

As I said, I don't see any commit in particular that fixes this issue but
V2.2-stable is the current release (and it is our long term release!)

Regards, Malahal.


Krishna Harathi [khara...@exablox.com  ] wrote:
>Using Ganesha version 2.1.0, NFSv3 exports and clients.
>We are seeing the following crash where Ganesha is trying to access parent
>inode to SetPostOpAttr() and ion the crash, we see that the parent
>obj_handle is NULL.
>Is this a known issue, and are there any recent fices in this area? Any
>help is
>appreciated.
>
>  Thread 1 (LWP 6688):
>  #0  0x0050ad94 in cache_inode_is_attrs_valid (entry=0x6b424500)
>  at /git/packaging/nfs-ganesha/nfs-ganesha/src/include/cache_inode.h:939
>  #1  0x0050e5d8 in cache_inode_lock_trust_attrs (entry=0x6b424500, 
> need_wr_lock=false)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/cache_inode/cache_inode_misc.c:887
>  #2  0x004a1e04 in cache_entry_to_nfs3_Fattr (entry=0x6b424500, 
> Fattr=0x698092f0)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/Protocols/NFS/nfs_proto_tools.c:3567
>  #3  0x0049a940 in nfs_SetPostOpAttr (entry=0x6b424500, attr=0x698092e8)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/Protocols/NFS/nfs_proto_tools.c:79
>  #4  0x0049abc8 in nfs_SetWccData (before_attr=0x70ffdc00, entry=0x6b424500, 
> wcc_data=0x698092c8)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/Protocols/NFS/nfs_proto_tools.c:132
>  #5  0x00466bbc in nfs3_remove (arg=0x5fc90358, worker=0x6f008140, 
> req=0x5fc902e8, res=0x698092c0)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/Protocols/NFS/nfs3_remove.c:161
>  #6  0x0045b340 in nfs_rpc_execute (req=0x5fc72d30, worker_data=0x6f008140)
>  at 
> /git/packaging/nfs-ganesha/nfs-ganesha/src/MainNFSD/nfs_worker_thread.c:1257
>  #7  0x0045bfa8 in worker_run (ctx=0x76562f00)
>  at 
> /git/packaging/nfs-ganes

[Nfs-ganesha-devel] Announce Push of V2.3-dev-10

[Frank Filz]

Branch next

Tag:V2.3-dev-10

NOTE: This introduces an update to libntirpc. Please update your submodule
and rebase any patches you push.

Highlights

* many RPC changes

Signed-off-by: Frank S. Filz 

Contents:

447ea1c Frank S. Filz V2.3-dev-10
c85f728 William Allen Simpson Add svc_req to svc_freeargs
bb49b72 William Allen Simpson Combine xp_ addresses into new struct
rpc_address
2a9610f William Allen Simpson Merge xp_ops with xp_ops2
00c21a6 William Allen Simpson Merge nfs_request_data into request_data
219ac39 William Allen Simpson Merge rpc_call into request_data
c523592 William Allen Simpson Move request count into xprt xp_requests
9bdfc2c William Allen Simpson Move duplicate record check pointer into xprt
xp_u2
2de2764 William Allen Simpson nTI-RPC update Jun 11, 2015
0706fe7 William Allen Simpson Remove fridge from nfs_rpc_dispatcher_thread
ec1cd34 William Allen Simpson Remove unused nfs_worker_data parameters
e07271f William Allen Simpson Move nfs_worker_data into fridgethr_context
5caac6a William Allen Simpson Redundant hostaddr storage in nfs_worker_data
8cb3ede William Allen Simpson Copy nfs_rpc_msk.c to _rdma.c
d033471 William Allen Simpson nfs thread entry declarations
7a820a2 William Allen Simpson Compile RDMA in Maintainer Mode


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] This week

[Frank Filz]

There will be no concall this week.

As of this time, I don't plan another dev-release this week. I just pushed
Bill's RPC changes (with libntirpc update) as dev-10. Please make sure you
rebase all patch submissions and make sure you update your sub-module. If by
Wednesday morning there is a reasonable set of patches, I may decide to do a
dev-11 on Wednesday, otherwise, dev-11 will be next week.

Thanks

Frank



--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] V2.3-dev-9 Coverity status

[Frank Filz]

> Thanks, Fredric.
> 
> This is a false positive; even though the switch is on a locally defined
> enumeration, the actual value comes off the wire, and so could be outside
> the enumeration.  This will be caught by the default clause, and
> -1 will be returned.

Hmm, I guess I should have looked at the code more carefully when
reviewing...

Using an enum for flag values that will be or-red together is not very
useful and probably confusing. Note that any combination of flags is not a
valid enum value... Just use #define to define the constants.

I would also change the value of PAN_FS_ACE_INVALID to non-zero and return
that from the function rather than casting -1.

Frank

> On 06/30/2015 02:35 AM, SAUNIER, FREDERIC wrote:
> > Hi Daniel,
> >
> > There is actually only one issue (reported by 2 different instances of
> coverity).
> > All details are available on online version at
> https://scan.coverity.com/projects/2187/view_defects.
> > If you are not registered yet to scan.coverity.com (you can either
> > sign up requesting a dedicated free account, or using your github
account) ,
> here are the details for convenience:
> >
> > src//nfs-ganesha/src/FSAL/FSAL_VFS/panfs/attrs.c:line 294
> > CID 120979 (#1 of 1): Operands don't affect result
> (CONSTANT_EXPRESSION_RESULT)
> > result_independent_of_operands: panace->info == 4294967295U /*
> (uint32_t)-1 */ is always false regardless of the values of its operands.
This
> occurs as the logical operand of if.
> >
> > Hope this helps,
> > -- Frederic
> >
> > -Original Message-
> > From: Daniel Gryniewicz [mailto:d...@cohortfs.com]
> > Sent: Monday, June 29, 2015 2:53 PM
> > To: nfs-ganesha-devel@lists.sourceforge.net
> > Subject: Re: [Nfs-ganesha-devel] V2.3-dev-9 Coverity status
> >
> > On 06/29/2015 08:48 AM, SAUNIER, FREDERIC wrote:
> >> Hi,
> >> This week, coverity analysis reports 2 new defects. Online Coverity
> >> results are available.
> >> Analysis summary report:
> >> 
> >> Files analyzed : 489
> >> Total LoC input to cov-analyze : 193248
> >> Functions analyzed : 4608
> >> Paths analyzed : 684454
> >> Here is updated list of  outstanding defects.
> >> Cheers,
> >> Frederic
> >>
> > Hi, Fredric.
> >
> > The PanFS attr ones are clearly introduced by my patches.  How do I find
> details about them?
> >
> > Thanks,
> > Daniel
> >
> > --
> >  Monitor 25 network devices or servers for free with
> > OpManager!
> > OpManager is web-based network management software that monitors
> > network devices and physical & virtual servers, alerts via email & sms
> > for fault. Monitor 25 devices for free with no restriction. Download
> > now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >
> > --
> >  Don't Limit Your Business. Reach for the Cloud.
> > GigeNET's Cloud Solutions provide you with the tools and support that
> > you need to offload your IT needs and focus on growing your business.
> > Configured For All Businesses. Start Your Cloud Today.
> > https://www.gigenetcloud.com/
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> 
> 
>

--
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that you
> need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Ganesha crash on a rm

[Frank Filz]

Oh, I thought someone had a fix…

 

Frank

 

From: Omkar Joshi [mailto:o...@hedviginc.com] 
Sent: Tuesday, June 30, 2015 3:43 PM
To: Frank Filz; Krishna Harathi; Omkar Joshi; nfs-ganesha-devel
Subject: Re: [Nfs-ganesha-devel] Ganesha crash on a rm

 

hey guys,

 

sorry.. missed it completely. Please let me know if I could be of any help.

 

On Mon, Jun 29, 2015 at 12:47 PM, Malahal Naineni mailto:mala...@us.ibm.com> > wrote:

Looks like we also hit this issue in our testing few days back.  I would
like a patch for 2.3 and back ported to 2.2 (maybe 2.1 as well).

Regards, Malahal.

Frank Filz [ffilz...@mindspring.com <mailto:ffilz...@mindspring.com> ] wrote:
>Did we ever get a fix for this submitted to gerrithub? That is the primary
>way we take fixes for current Ganesha development (V2.3). Issues for
>previous releases should be fixed in current next first or at least be
>submitted first before being submitted for previous releases.
>
>
>
>Thanks
>
>
>
>Frank
>
>
>
>From: Krishna Harathi [mailto:khara...@exablox.com 
> <mailto:khara...@exablox.com> ]
>Sent: Monday, June 29, 2015 9:31 AM
>To: Omkar Joshi
>Cc: nfs-ganesha-devel
>Subject: Re: [Nfs-ganesha-devel] Ganesha crash on a rm
>
>
>
>Ok, found your fix
>- [1]https://bugzilla.redhat.com/show_bug.cgi?id=1218422
>
>
>
>I will test your fix with the test-cases we have.
>
>Regards.
>
>Krishna Harathi
>
>
>
>On Fri, Jun 19, 2015 at 3:32 PM, Krishna Harathi <[2]khara...@exablox.com 
> <mailto:khara...@exablox.com> >
>wrote:
>
>  I will certainly pick up the fix and try it asap, thanks for pointing it
>  out.
>
>  Regards.
>
>  Krishna Harathi
>
>
>
>  On Fri, Jun 19, 2015 at 11:50 AM, Omkar Joshi <[3]o...@hedviginc.com 
> <mailto:o...@hedviginc.com> >
>  wrote:
>
>check cache inode related bug which I had raised on red hat bugzilla.
>It may be related to that... I have posted the fix for this.
>
>
>
>On Thu, Jun 18, 2015 at 8:15 AM, Krishna Harathi

><[4]khara...@exablox.com <mailto:khara...@exablox.com> > wrote:
>
>  Hi Malahal,
>
>
>
>  We are using VFS FSAL.
>
>
>
>  In the original email, I noted that the parent cache entry in
>  question is qid = LRU_ENTRY_CLEANUP, so I guess the cache entry is
>  in the cleanup queue, whereas this thread in question is trying to
>  access the entry to fill up some post-op attributes in the NFS
>  reply.
>
>
>
>  The workload is "rm -rf" of 1000K files that runs for couple of
>  days, with other IO in parallel, it does not crash always and it is
>  hard to re-create.  My guess of what is happening here is - a file
>  is getting removed
>
>
>
>  Also, we cannot pick up Ganesha 2.2 because of our release cycles,
>  it is in the plan, it came out only recently.
>
>  Having said that,  the crash you see is with Ganesha 2.1.0 +
>  refcount and other patches from 2.2.0.  As you said, I also suspect
>  2.2 may not fix this issue,
>
>
>
>  I just need help in debugging, my question is - when a directory
>  entry is getting removed, at the time of filling up the postOp
>  attributes from the parent Directory cache entry, what lock is
>  supposed to be held on the parent entry? Also, the remove operation
>  has returned with error from the VFS FSAL.
>
>
>
>  valgrind does not show any use-after-free errors or any other
>  significant errors, only a bunch of allocated-but-not-freed memory
>  at the end on normal exit, and that is usual for Ganehsa I guess?
>
>
>
>  Regards.
>
>  Krishna Harathi
>
>
>
>  On Wed, Jun 17, 2015 at 6:36 AM, Malahal Naineni

>  <[5]mala...@us.ibm.com <mailto:mala...@us.ibm.com> > wrote:
>
>Hi Krishna, The code doesn't seem to match exactly with V2.1.0 but
>it
>does look like nfs3_remove() entered label "out_fail". Wondering
>what
>the cache_status was at the time of the crash.
>
>There were some fixes in V2.2-stable related refcounting, but I am
>not
>sure if V2.2-stable fixes your issues.
>
>What FSAL are you using? Also, if you can reproduce this under
>valgrind,
>that should give us more information to see if we are using the
>fre

[Nfs-ganesha-devel] Reminder no concall this week

[Frank Filz]

I am out on company holiday Thursday and Friday so no concall this week.

Also, there will not be a merge this week.

See you next week for concall and dev-11 merge.

Frank


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] custom FSAL to access storage from another user space process

[Frank Filz]

I think FSAL_PT interfaces via IPC with another process, though that IPC may
be in an out of tree library.

You might want to look at a lighter IPC than TCP/UDP.

If you are defining your own IPC, obviously you can make the API for that
mirror the FSAL API.

Ganesha uses a single multi-threaded process. It uses thread pools to
distribute work (so threads are not dedicated to specific clients).

There are rwlocks at the cache inode layer that do MOST of the protection
necessary for FSAL objects (the FSAL may have lists or tables of objects
that need their own protection, and there are some "file descriptor" things
that aren't sufficiently protected by the cache inode locks).

Matt makes some good suggestions on FSALs to start looking at, however there
are some bits and pieces that are not well implemented by those FSALs:

Range lock integration - Ganesha can manage range locks entirely internally,
however, if you have other remote file system protocols or local processes,
you need to push range locks down into the underlying filesystem. To do this
fully, there needs to be some way to support multiple lock owners and
asynchronous blocking locks.

Share reservation integration - Ganesha again can manage these all by
itself, but again, if you want integration with other remote file system
protocols, you need to drive these into the underlying file system.

If you care about NFS v3 clients mounting sub-directories under the export,
you need to make sure lookup_path works as expected.

If you have multiple file systems where inode numbers and/or handles can
collide, you need to do some work to handle that.

You probably need some kind of cache invalidation upcall mechanism.

Then there are things like ACLs...

For the above concerns, the most implemented FSAL is FSAL_GPFS. FSAL_GLUSTER
is also well implemented. Actually, FSAL_GLUSTER may also do some IPC stuff.

Frank

> Well, the proxy fsal proxies to another NFS server over TCP or UDP, so you
> might find that helpful.
> 
> The Ceph fsal is a fairly minimal example of a fsal that delegates to a
library
> with a posix-like api.
> 
> The problem of how to do IPC between your fsal and a remote using a
> custom protocol is not one Ganesha solves per se.  You could do a lot of
> things, obviously.
> 
> Matt
> 
> - "Dirk Jagdmann"  wrote:
> 
> > Hello developers,
> >
> > I'm currently evaluating how to best integrate NFS-Ganesha with our
> > storage product. My company is developing a user space Linux
> > application to handle storage and we'd like to provide a NFS service
> > to access files and directories.
> >
> > As a proof of concept we've currently used the Linux FUSE feature to
> > expose our storage as a regular Linux VFS handled filesystem, and
> > NFS-Ganesha can use this just fine. However using FUSE to pass data
> > between 2 user space processes is probably not the best solution and
> > also probably not the fastest solution. I'm therefore currently
> > investigating how feasible it is to develop a custom FSAL, which will
> > communicate directly with another user space process. I'm thinking
> > about writing a simple "network protocol" which will forward the FSAL
> > calls to our storage user space process. It could use a stream or
> > datagram style "connection", which could be regular TCP/UDP, maybe
> > unix domain sockets, maybe Linux netlink sockets, maybe even SysV
> > shared memory (if that's even necessary for performance).
> >
> > I did read all the NFS-Ganesha Wiki pages and read the fsal_api.h
> > header once, and have a couple of questions now:
> >
> > - does the NFS-Ganesha server use multiple processes or multiple
> > threads?
> >
> > - if it does use multiple process/threads, how are multiple connected
> > NFS clients multiplexed to the processes/threads?
> >
> > - if multiple threads are used, how are the FSAL objects allocated and
> > used with regards to the threads? Is locking required "inside" the
> > FSAL implementation?
> >
> > - did anybody write a FSAL which forwards the calls made from
> > NFS-Ganesha to the FSAL objects to another process? I'm thinking about
> > writing a FSAL with a generic protocol which different user space
> > processes can connect to and provide the storage/files/directories.
> >
> > - looking at the current FSAL implementations, which is the simplest
> > to get me started, but implements all the necessary features? I'm
> > thinking about studying the implementation and using that as a
> > template for my own FSAL.
> >
> >
> > --
> > ---> Dirk Jagdmann
> > > http://cubic.org/~doj
> > -> http://llg.cubic.org
> >
> > --
> >  Don't Limit Your Business. Reach for the Cloud.
> > GigeNET's Cloud Solutions provide you with the tools and support that
> > you need to offload your IT needs and focus on growing your business.
> > Configured For All Businesses. Start Your Cloud Today.
> > https://www.gigenetcloud.com/
> > _

[Nfs-ganesha-devel] Announce Push of V2.3-dev-11

[Frank Filz]

Branch next

Tag:V2.3-dev-11

NOTE: This introduces an update to libntirpc. Please update your submodule
and rebase any patches you push.

Highlights

* changes to allow building on FreeBSD 10.1

* allow multiple DSs

* export "/" for NFS v3

* add 9p stats

* grace struct cleanup

* fix splitting locks

* return NFS4ERR_BAD_RANGE or NLM_FBIG if lock range is too large

* FSAL_GLUSTER create with O_EXCL

* Do not register NFS if configuration file does not ask for NFS support

* NFSv4.1/pNFS/Flexible Files: add Flexible Files Layout XDR definition

* FSAL_GLUSTER ACL fixes

* Make sure we have an fs_locations attribute before returning NFS4ERR_MOVED

* Use rwlock to protect FSAL_VFS file descriptor

* gpfs: Handle THREAD_PAUSE event from GPFS upcall

Signed-off-by: Frank S. Filz 

Contents:

b4d7c11 Frank S. Filz V2.3-dev-11
b8c7ee2 Frank S. Filz Add bsd10.cmake
43cf5a1 Daniel Gryniewicz DS Handle - allow multiple DSs
413b6d2 Aihua Zhang mnt_Mnt: can't export path "/" while the nfs version is
3
2fae5e1 Gregoire Pichon 9P/DBUS: Add 9p protocol operations statistics
c10b2d4 Malahal Naineni Remove unneeded memset for cid_recov_dir buffer!
2bd5928 Malahal Naineni gpfs: Handle THREAD_PAUSE event from GPFS upcall
c348d61 Allison Henderson Clean up grace struct
8758264 Allison Henderson Remove grace timer from g_mutex
eebb156 Soumya Koduri FSAL_GLUSTER: Include 'O_EXCL' flag while trying to
create a file
24cce66 Soumya Koduri FSAL_GLUSTER: Bail out in case of larger lock ranges
(>INT64_MAX)
facaa58 Soumya Koduri lock: Fixed an issue with lock_length while splitting
locks
1eafceb Philippe DENIEL Do not register NFS if configuration file does not
ask for NFS support
1fc8821 Philippe DENIEL NFSv4.1/pNFS/Flexible Files: add Flexible Files
Layout XDR definition
42c180e Jiffin Tony Thottan FSAL_GLUSTER : fix possible memory corruption
for inherit acl conversion
e475da7 Jiffin Tony Thottan FSAL_GLUSTER : Ignore dead links for acl fetch
operation
e3e0760 Jiffin Tony Thottan FSAL_GLUSTER : invalid usage of is_dir variable
in acl api's
1717ed1 Frank S. Filz Make sure we have an fs_locations attribute before
returning NFS4ERR_MOVED
82c3323 Frank S. Filz Use rwlock to protect FSAL_VFS file descriptor
8b180f4 Matt Benjamin Update ntirpc submodule
9d6b66c Frank S. Filz Be consistent about using misc/queue.h instead of
sys/queue.h
81edf3f Frank S. Filz Fix Ganesha to compile on FreeBSD 10.1
87dbbc8 Frank S. Filz Fix up FreeBSD specific code so it actually compiles
and runs on PANFS
f1f2dbb Frank S. Filz Remove dead code exposed by strict compile on FreeBSD
10.1
cee54c8 Frank S. Filz Fix code bugs exposed by strict compile on FreeBSD
10.1
53a9473 Frank S. Filz Fix strict compile errors shown up by FreeBSD 10.1
a0dc317 Frank S. Filz Replace fixed size handle structures with NFS3_FHSIZE
and NFS4_FHSIZE
627a00d Frank S. Filz Convert deleg_revoke to return nfsstat4
f08ff9d Frank S. Filz Reorganize fsal_acl_to_mode and rename setmode to
set_mode


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] FW: New Defects reported by Coverity Scan for nfs-ganesha

[Frank Filz]

Looks like a bunch of new Coverity defects in the online Coverity. Primarily 
ntirpc related.

See the online report:

https://scan.coverity.com/projects/2187/view_defects

-Original Message-
From: scan-ad...@coverity.com [mailto:scan-ad...@coverity.com] 
Sent: Friday, July 10, 2015 12:56 AM
To: ffilz...@mindspring.com
Subject: New Defects reported by Coverity Scan for nfs-ganesha


Hi,

Please find the latest report on new defect(s) introduced to nfs-ganesha found 
with Coverity Scan.

10 new defect(s) introduced to nfs-ganesha found with Coverity Scan.
12 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan Showing 10 of 10 defect(s)


** CID 124499:  Resource leaks  (RESOURCE_LEAK)
/nfs-ganesha/src/libntirpc/src/xdr_ioq.c: 291 in xdr_ioq_create()



*** CID 124499:  Resource leaks  (RESOURCE_LEAK)
/nfs-ganesha/src/libntirpc/src/xdr_ioq.c: 291 in xdr_ioq_create()
285 struct xdr_ioq_uv *uv = xdr_ioq_uv_create(min_bsize, 
uio_flags);
286 xioq->ioq_uv.uvqh.qcount = 1;
287 TAILQ_INSERT_HEAD(&xioq->ioq_uv.uvqh.qh, &uv->uvq, q);
288 xdr_ioq_reset(xioq, 0);
289 }
290 
>>> CID 124499:  Resource leaks  (RESOURCE_LEAK)
>>> Variable "xioq" going out of scope leaks the storage it points to.
291 return (xioq->xdrs);
292 }
293 
294 /*
295  * Advance read/insert or fill position.
296  *

** CID 124498:  Concurrent data access violations  (MISSING_LOCK)
/nfs-ganesha/src/libntirpc/src/svc_vc.c: 1210 in svc_vc_override_ops()



*** CID 124498:  Concurrent data access violations  (MISSING_LOCK)
/nfs-ganesha/src/libntirpc/src/svc_vc.c: 1210 in svc_vc_override_ops()
1204 }
1205 
1206 static void
1207 svc_vc_override_ops(SVCXPRT *xprt, SVCXPRT *newxprt)
1208 {
1209if (xprt->xp_ops->xp_getreq)
>>> CID 124498:  Concurrent data access violations  (MISSING_LOCK)
>>> Accessing "newxprt->xp_ops->xp_getreq" without holding lock "ops_lock". 
>>> Elsewhere, "xp_ops.xp_getreq" is accessed with "ops_lock" held 7 out of 8 
>>> times (3 of these accesses strongly imply that it is necessary).
1210newxprt->xp_ops->xp_getreq = xprt->xp_ops->xp_getreq;
1211if (xprt->xp_ops->xp_dispatch)
1212newxprt->xp_ops->xp_dispatch = 
xprt->xp_ops->xp_dispatch;
1213if (xprt->xp_ops->xp_recv_user_data)
1214newxprt->xp_ops->xp_recv_user_data = 
xprt->xp_ops->xp_recv_user_data;
1215if (xprt->xp_ops->xp_free_user_data)

** CID 124497:  Concurrent data access violations  (MISSING_LOCK)
/nfs-ganesha/src/libntirpc/src/svc_vc.c: 1214 in svc_vc_override_ops()



*** CID 124497:  Concurrent data access violations  (MISSING_LOCK)
/nfs-ganesha/src/libntirpc/src/svc_vc.c: 1214 in svc_vc_override_ops()
1208 {
1209if (xprt->xp_ops->xp_getreq)
1210newxprt->xp_ops->xp_getreq = xprt->xp_ops->xp_getreq;
1211if (xprt->xp_ops->xp_dispatch)
1212newxprt->xp_ops->xp_dispatch = 
xprt->xp_ops->xp_dispatch;
1213if (xprt->xp_ops->xp_recv_user_data)
>>> CID 124497:  Concurrent data access violations  (MISSING_LOCK)
>>> Accessing "newxprt->xp_ops->xp_recv_user_data" without holding lock 
>>> "ops_lock". Elsewhere, "xp_ops.xp_recv_user_data" is accessed with 
>>> "ops_lock" held 6 out of 7 times (2 of these accesses strongly imply that 
>>> it is necessary).
1214newxprt->xp_ops->xp_recv_user_data = 
xprt->xp_ops->xp_recv_user_data;
1215if (xprt->xp_ops->xp_free_user_data)
1216newxprt->xp_ops->xp_free_user_data = 
xprt->xp_ops->xp_free_user_data;
1217 }
1218 
1219 static void

** CID 124496:  Concurrent data access violations  (MISSING_LOCK)
/nfs-ganesha/src/libntirpc/src/work_pool.c: 83 in work_pool_init()



*** CID 124496:  Concurrent data access violations  (MISSING_LOCK)
/nfs-ganesha/src/libntirpc/src/work_pool.c: 83 in work_pool_init()
77  pool->params = *params;
78 
79  if (pool->params.thrd_max < 1) {
80  __warnx(TIRPC_DEBUG_FLAG_ERROR,
81  "%s() thrd_max (%d) < 1",
82  __func__, pool->params.thrd_max);
>>> CID 124496:  Concurrent data access violations  (MISSING_LOCK)
>>> Accessing "pool->params.thrd_max" without holding lock 
>>> "poolq_head.qmutex". Elsewhere, "work_pool_par

Re: [Nfs-ganesha-devel] FW: New Defects reported by Coverity Scan for nfs-ganesha

[Frank Filz]

> On 7/12/15 8:05 AM, William Allen Simpson wrote:
> 
> Noting that I've had for some weeks (Jun 19) a replacement for
> SVC_RELEASE() that uses an inline function instead.
> Coverity seems to be better with inline, so this will probably go away on its
> own.
> 
> That patch happens to be called:
> "Convert svc_destroy and references to inline atomics"
> 
> Eliminates a dozen of the most common transport [un]lock pairs.
> 
> Also uses atomic to set xp_flags.
> 
> Frank, do we want it this week?  This is another we need for speed, and will
> need lots of testing.
> 
> 
> >> ** CID 124492:  Program hangs  (LOCK)
> >> /nfs-ganesha/src/libntirpc/src/svc_ioq.c: 206 in svc_ioq_callback()
> >>
> > False positive.  Somebody needs to teach Coverity to expand macros.
> >
> Probably not just expand macros, but check call vectors.  May be too hard for
> it

Coverity is unable to track these flags that control lock/unlock. Inline 
doesn't help it any.

I always mark these as intentional and move on.

Coverity may log a new issue when you make it inline...

Frank

> >> *** CID 124492:  Program hangs  (LOCK)
> >> /nfs-ganesha/src/libntirpc/src/svc_ioq.c: 206 in svc_ioq_callback()
> >> 200 for (;;) {
> >> 201 mutex_lock(&xprt->xp_lock);
> >> 202 have = TAILQ_FIRST(&xd->shared.ioq.qh);
> >> 203 if (unlikely(!have || !svc_work_pool.params.thrd_max)) {
> >> 204 xd->shared.active = false;
> >> 205 SVC_RELEASE(xprt, SVC_RELEASE_FLAG_LOCKED);
> >  CID 124492:  Program hangs  (LOCK)
> >  Returning without unlocking "xprt->xp_lock".
> >> 206 return;
> >> 207 }
> >> 208
> >> 209 TAILQ_REMOVE(&xd->shared.ioq.qh, have, q);
> >> 210 (xd->shared.ioq.qcount)--;
> >> 211 /* do i/o unlocked */


--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] FW: New Defects reported by Coverity Scan for nfs-ganesha

[Frank Filz]

Looks like we can clear all of these. I think they should mostly all be marked 
as intentional, our use of flags to control when lock/unlock is done is hard 
for an automated tool to follow (it's not even always that clear to me... I 
wish in some cases we would use functions like foo_locked that assumes the lock 
is held, and inline foo that takes the lock and calls foo_locked for those 
callers that don't already hold the lock...

Matt, would you mind going into Coverity and clearing all of these?

Thanks

Frank

> -Original Message-
> From: William Allen Simpson [mailto:william.allen.simp...@gmail.com]
> Sent: Sunday, July 12, 2015 5:06 AM
> To: Frank Filz; 'NFS Ganesha Developers'
> Subject: Re: FW: New Defects reported by Coverity Scan for nfs-ganesha
> 
> On 7/10/15 10:45 AM, Frank Filz wrote:
> > Looks like a bunch of new Coverity defects in the online Coverity. Primarily
> ntirpc related.
> >
> Thanks.
> 
> Heh, not exactly ;)
> 
> 
> > See the online report:
> >
> > https://scan.coverity.com/projects/2187/view_defects
> >
> > -Original Message-
> > From: scan-ad...@coverity.com [mailto:scan-ad...@coverity.com]
> > Sent: Friday, July 10, 2015 12:56 AM
> > To: ffilz...@mindspring.com
> > Subject: New Defects reported by Coverity Scan for nfs-ganesha
> >
> >
> > Hi,
> >
> > Please find the latest report on new defect(s) introduced to nfs-ganesha
> found with Coverity Scan.
> >
> > 10 new defect(s) introduced to nfs-ganesha found with Coverity Scan.
> > 12 defect(s), reported by Coverity Scan earlier, were marked fixed in the
> recent build analyzed by Coverity Scan.
> >
> > New defect(s) Reported-by: Coverity Scan Showing 10 of 10 defect(s)
> >
> >
> > ** CID 124499:  Resource leaks  (RESOURCE_LEAK)
> > /nfs-ganesha/src/libntirpc/src/xdr_ioq.c: 291 in xdr_ioq_create()
> >
> >
> >
> __
> 
> > __
> > *** CID 124499:  Resource leaks  (RESOURCE_LEAK)
> > /nfs-ganesha/src/libntirpc/src/xdr_ioq.c: 291 in xdr_ioq_create()
> > 285 struct xdr_ioq_uv *uv =
> xdr_ioq_uv_create(min_bsize, uio_flags);
> > 286 xioq->ioq_uv.uvqh.qcount = 1;
> > 287 TAILQ_INSERT_HEAD(&xioq->ioq_uv.uvqh.qh, &uv-
> >uvq, q);
> > 288 xdr_ioq_reset(xioq, 0);
> > 289 }
> > 290
> >>>>  CID 124499:  Resource leaks  (RESOURCE_LEAK)
> >>>>  Variable "xioq" going out of scope leaks the storage it points to.
> > 291 return (xioq->xdrs);
> > 292 }
> 
> False positive. xioq is a container wrapped around the XDR. The XDR is an
> array of one. This C shortcut is the same as &xioq->xdrs[0]. Somebody needs
> to teach Coverity about array pointers (something beginners often find
> confusing).
> 
> This technique has been used everywhere since xdr_ioq was introduced
> some years ago.

I wonder if it would do ok even if the return WAS &xiod->xdrs[0]...

> > 293
> > 294 /*
> > 295  * Advance read/insert or fill position.
> > 296  *
> >
> > ** CID 124498:  Concurrent data access violations  (MISSING_LOCK)
> > /nfs-ganesha/src/libntirpc/src/svc_vc.c: 1210 in svc_vc_override_ops()
> >
> Heavy sigh. False positive.
> 
> The locks merely prevent 2 _inits from running at the same time, apparently
> by dbus -- but the fields are always set to the same values.
> 
> Moreover, address access is usually atomic (on 64-bit processors), and this
> could be made explicit with atomic operators.
> 
> So the pointer is idempotent for access, and correct here.
> 
> Moreover, Coverity only looked at this because of a name change.
> The operations are exactly the same as they always have been.

Mark this one as intentional.

> __
> 
> > __
> > *** CID 124498:  Concurrent data access violations  (MISSING_LOCK)
> > /nfs-ganesha/src/libntirpc/src/svc_vc.c: 1210 in svc_vc_override_ops()
> > 1204 }
> > 1205
> > 1206 static void
> > 1207 svc_vc_override_ops(SVCXPRT *xprt, SVCXPRT *newxprt)
> > 1208 {
> > 1209if (xprt->xp_ops->xp_getreq)
> >>>>  CID 124498:  Concurrent data access violations  (MISSING_LOCK)
> >>>>  Accessing "newxprt->xp_ops->xp_getreq" without holding lock
> "ops_lock". Elsewhere, "xp_ops.xp_getreq

[Nfs-ganesha-devel] Our list is working again!

[Frank Filz]

Nothing to see here, run along now folks...

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Call tomorrow, merge this week

[Frank Filz]

We will have a call tomorrow (well, I guess later today for some...) and we
will discuss what is to be merged this week.

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-12

[Frank Filz]

Branch next

Tag:V2.3-dev-12

Highlights

* NEW LogWarnOnce macro (will log a warning and then never speak up again)

* Call do_unlock_no_owner for 9P (previously was not called)

* VFS/LUSTRE lock_op: don't override return status to fill conflicting_lock

* Fix inode reference miscount when removing an entry

* Several packaging related patches

* Add short_file_handle config option

* GPFS cleanup

* Lustre: warn on restrictive .lustre/fid permissions

Signed-off-by: Frank S. Filz 

Contents:

b8bddd0 Frank S. Filz V2.3-dev-12
6824f77 Omkar Joshi Fix inode reference miscount when removing an entry.
0658009 Philippe DENIEL TRAVIS/CI: Disable FSAL_CEPH from TRAVIS-CI job
54a2323 Dominique Martinet state_lock: do unlock for 9P
0be23a1 Dominique Martinet VFS/LUSTRE lock_op: don't override return status
to fill conflicting_lock
a4f59aa Dominique Martinet Lustre: warn on restrictive .lustre/fid
permissions
0bac5cf Malahal Naineni nfs-ganesha-utils package requires dbus-python and
pygobject
419992b Malahal Naineni Fix building rpms with cmake
-DUSE_GUI_ADMIN_TOOLS=OFF
4fcf75c Malahal Naineni Remove gpfs_malloc_handle and inline
gpfs_alloc_handle
87c21d2 Malahal Naineni Add short_file_handle config option
32606c7 Frank S. Filz Add LogWarnOnce macro


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Latest efforts on multiple-file descriptors pushed to gerrithub - Please have a look

[Frank Filz]

NOTE: All the patches that don't begin with FYI are candidates for earlier
merging, please review these with an eye to including them next week.

The multiple file descriptor work is far from complete, but it's starting to
get to a point where the intent starts to be visible from the
implementation.

Thanks

Frank



--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Client specification question

[Frank Filz]

> > Is there any read/write performance hit by using multiple CLIENT
> > sections in configuration to filter client access?

The list of clients allowed access to an export is a linear linked list, so
if you had LOTS of client entries (whether in one CLIENT block or multiple),
there could be a noticeable performance impact.

> > Also I assume IPv6 addresses can be given, although the configuration
> > examples does not mention IPv6?

Yes, IPv6 addresses may be used. IPv6 clients however are not matched
against host names, net masks, or net groups.

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] FW: The Fall Bakeathon in Westford, Ma

[Frank Filz]

-Original Message-
From: linux-nfs-ow...@vger.kernel.org
[mailto:linux-nfs-ow...@vger.kernel.org] On Behalf Of Steve Dickson
Sent: Tuesday, July 21, 2015 1:29 PM
To: NFSv4; Linux NFS Mailing list
Subject: The Fall Bakeathon in Westford, Ma

Red Hat is pleased to announce the Fall NFS Bake-a-ton will be hosted by Red
Hat in Westford, MA office The Date: *Oct 12th - 16th*

Details and registration info:
http://nfsv4bat.org/Events/2015/October/BAT/index.html

Something new this year... RDMA testing! I was able to secure a side room
off one of the conference room where we can put the noisy machinery... So
RDMA testing is on! 

Once again I have blocked some rooms at two different hotels this year. The
Westford Regency Inn and Hampton Inn.

The Westford Regency Inn now has a  shuttle bus to/from the Red Hat office
as well as some updated rooms, ask for them. 

The Hampton Inn is much newer but a bit more expensive and not as close the
Westford Regency but walking distance to a couple of decent restaurants.
Plus a free breakfast as all Hampton Inn do. 

Please book *asap* since there is a limited number of rooms at the Red Hat
rate.  

When registering (i.e. replying to this email) please give me
   * Company Name
   * How engineers are coming
   * T-shirt sizes
   * Hotel you will be staying in

I hope to see you in October!!!

steved.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the
body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Fix submission process

[Frank Filz]

> On Mon, Jul 27, 2015 at 09:22:50AM -0500, Malahal Naineni wrote:
> > Niels de Vos [nde...@redhat.com] wrote:
> > > On Sun, Jul 26, 2015 at 11:00:29AM -0700, Krishna Harathi wrote:
> > > > Can someone point me to a fix submission process document or a
> summary?
> > > >
> > > > I looked at Ganesha wiki as well as read some past email. I came
> > > > across some recent email from Frank and others on this subject,
> > > > but I am not clear on the process.
> > >
> > > I think this is the page and section that should help you:
> > >
> > >
> > > https://github.com/nfs-ganesha/nfs-ganesha/wiki/DevPolicy#patch-
> subm
> > > ission-guidelines
> > >
> > > Basically, you need to create an account (with your GitHub
> > > credentials) on http://gerrithub.io and add a public ssh-key in your
> > > account settings. After that, you should clone (or add the remote)
> > > based on this URL
> > >
> > >   $ git clone
> > > ssh://${GITHUB_USERNAME}@review.gerrithub.io:29418/ffilz/nfs-
> ganesha
> >
> > We still use github branch (not gerrithub) as the official repo, right?
> > In any case, I actually cloned my repo from
> >
> > https://github.com/nfs-ganesha/nfs-ganesha.git
> >
> > I have gerrithub remote "https://gerrithub.io/ffilz/nfs-ganesha";
> > exclusively for pushing patches.
> 
> I dont know if that makes a difference. The github.com is probably the
> "official" repository, but it should be in sync with what gerrithub
provides.

I'm not sure if the next on gerrithub gets the signed tags. I suppose it
must (I don't push them separately like I do to github).

Not likely to be TOO much of an issue since any patches are cherry picked or
rebased during my merge.

Frank

> > > Patches are sent against the "next" branch, and it is easiest to
> > > create one branch per patch(-series):
> > >
> > >   $ git checkout -t -b my-fixes-for-foo origin/next
> > >
> > > Once you have committed and tested your changes, you can push them
> > > to gerrithub. I prefer to use the git-review tool for that:
> > >
> > >   $ git review -t my-fixes-for-foo
> >
> > Is the "review" command specific to gerrithub? I use it to download
> > someone else patch(es) from gerrithub. It just hung on a regular commit!
> > I use "git difftool" for reviewing my own patch(es).
> 
> git-review is specific to Gerrit. I only use it to post my own changes and
> download changes from others for review, but it can do more. The only
> reason I can think of why it would hang, is when you have multiple git
> remotes in your repository, and git-review tries to use an incorrect one.
You
> could try posting your change with
> 
>   $ git review -r gerrithub -t my-fixes-for-foo
> 
> Cheers,
> Niels
> 
>

--
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Multiple-fd work

[Frank Filz]

We may need to devote a concall to discussing this work, but I'm going to
try a modest length discussion of the approach I'm taking and why.

Ultimately, this effort got kicked off due to the stupid POSIX lock behavior
which really only impacts FSAL_VFS, but then when we started talking about
possibly not forcing a one-to-one mapping between file descriptors and
object handles, Marc Eshel suggested he could benefit from file descriptors
associated with individual NFS v4 OPENs so that GPFS's I/O prediction could
do better. And then Open File Descriptor Locks came along which opens
FSAL_VFS up to being able to have a much improved lock interface beyond just
being able to dodge the stupid POSIX lock behavior.

And as I got into thinking I realized, hey, to get full share reservation
and lock support in FSAL_PROXY, we need to be able to associate open and
lock stateids with Ganesha stateids.

So now we have:

FSAL_GPFS would like to have a file descriptor per OPEN (well, really per
OPEN stateid, tracking OPEN upgrade and OPEN_DOWNGRADE), and maybe one per
NFS v3 client

FSAL_VFS would like to have a file descriptor per lock owner per file.

FSAL_PROXY would like to have a stateid per OPEN stateid and LOCK stateid

FSAL_LUSTRE actually also uses fcntl to get POSIX locks, so it has the same
issues as FSAL_VFS.

Now I don't know about other FSALs, though I wouldn't be surprised if at
least some other FSALs might benefit from some mechanism to associate
SOMETHING with each lock owner per file.

So I came up with the idea of the FSAL providing the size of the "thing"
(which I have currently named fsal_fd, but we can change the name if it
would make folks feel more comfortable) with each Ganesha stateid. And then
to bring NFS v3 locks and share reservations into the picture, I've made
them able to use stateids (well, state_t structures), which also cleaned up
part of the SAL lock interface (since NFS v3 can hide it's "state" value in
the state_t and stop overloading state_t *state...

Now each FSAL gets to define exactly what an fsal_fd actually is. At the
moment I have the open mode in the generic structure, but maybe it can move
into the FSAL private fsal_fd.

Not all FSALs will use both open and lock fds, and we could provide separate
sizes for them so space would only be allocated when necessary (and if zero,
a NULL pointer is passed).

For most operations, the object_handle, and both a share_fd and lock_fd are
passed. This allows the FSAL to decide exactly which ones it needs (if it
needs a generic "thing" for anonymous I/O it can stash a generic fsal_fd in
it's object_handle).

The benefit of this interface is that the FSAL can leverage cache inode AVL
tree and SAL hash tables without making upcalls (that would be fraught with
locking issues) or duplicating hash tables in order to store information
entirely separately. It also may open possibilities to better hinting
between the layers so garbage collection can be improved.

In the meantime, the legacy interface is still available. If truly some
FSALs will never need this function, but they want to benefit from the
atomic open/create/setattr capability of FSAL open_fd method, we can make a
more generic version of that (well, actually, it just needs to be ok having
NULL passed for the fsal_fd).

I'm also thinking that eventually the cache inode content_lock will no
longer be what protects the generic "thing". Already FSAL_VFS is using the
object_handle lock to protect access to the fd associated with the
object_handle. Removing the need to hold content_lock would mean FSAL_VFS
could actually manage IT's number of open file descriptors and do some
management of them (maybe still in conjuction with cache inode to benefit
from the LRU table). But for example, a setattr or getattr call could result
in an open fd that FSAL_VFS would not immediately close.

There is an eventual goal of getting rid of the insane logic SAL has to
manage lock state when the FSAL supports locks but does not support lock
owners. This logic is not too bad on LOCK requests, but UNLOCK requires
walking the entire lock list for a file to figure out what portions of the
UNLOCK request are held by other lock owners. This can result in N+1 lock
requests (and memory objects) to perform unlock (where N is the number of
locks held by other lock owners).

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Missing files from directory with large entries

[Frank Filz]

Hmm, that looks like a constant that needs to be replaced with a config value…

 

That does appear to be an absolute hard limit on directory size (and if there 
are multiuple READDIR operations in progress, it would seem like you need even 
more).

 

One option would be to make it some percentage of the number of cache inodes 
allowed if we didn’t want to introduce a new config option.

 

Frank

 

From: Krishna Harathi [mailto:khara...@exablox.com] 
Sent: Monday, July 27, 2015 5:53 PM
To: nfs-ganesha-devel
Subject: [Nfs-ganesha-devel] Missing files from directory with large entries

 

In a test-case, we are finding that a few files(5) are missing  sometimes from 
a directory with  > 100K entries, while listing with "ls".

 

Debug logging is showing multiple entries with the following.

 

nfs-ganesha-5025[work-15] cache_inode_avl_insert_impl :INODE :DEBUG :inserted 
new dirent on entry=0x6780d300 cookie=1925138672 collisions 1 

 

I saw that in cache_inode_avl_insert_impl(), if I double this value of the 
check below, the problem

goes away apparently.

 

if ((!node) && (avltree_size(c) > 65535)) {
/* ie, recycle the smallest deleted entry */
node = avltree_first(c);
}

 

 

Any insight into this problem is appreciated, we are using Ganesha 2.1.0. I 
also looked at recent changes/fixes in this area in the current code I don't 
think the recent code addresses this issue, but I may be wrong.




Regards.

Krishna Harathi

--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Multiple-fd work

[Frank Filz]

> Hi Frank, list.
> 
> Frank Filz wrote on Mon, Jul 27, 2015 at 09:33:54AM -0700:
> > FSAL_LUSTRE actually also uses fcntl to get POSIX locks, so it has the
> > same issues as FSAL_VFS.
> 
> LUSTRE would actually like one fd per open or equivalent if we can reap them
> efficiently, for the same reason as GPFS -- sharing a fd kills readahead
> behaviour and lustre needs the client to do readahead and has us disable
> readahead disk-side, so ganesha performs quite worse with multiple clients.
> 
> Well, I guess that's close enough to what we're doing anyway.

Fds that are associated with NFS 4 OPEN or NFS 3 SHARE will be closed 
appropriately. If the FSAL didn't need to keep them open, we could enhance the 
cache inode LRU to be able to consider pinned entries for advisory file close. 
The FSAL could also try to do something to keep track and I dunno, LRU garbage 
collection of idle file descriptors might actually belong in the FSAL anyway 
instead of cache inode.

> > Now I don't know about other FSALs, though I wouldn't be surprised if
> > at least some other FSALs might benefit from some mechanism to
> > associate SOMETHING with each lock owner per file.
> >
> > So I came up with the idea of the FSAL providing the size of the "thing"
> > (which I have currently named fsal_fd, but we can change the name if
> > it would make folks feel more comfortable) with each Ganesha stateid.
> > And then to bring NFS v3 locks and share reservations into the
> > picture, I've made them able to use stateids (well, state_t
> > structures), which also cleaned up part of the SAL lock interface
> > (since NFS v3 can hide it's "state" value in the state_t and stop 
> > overloading
> state_t *state...
> 
> 9P has a state_t per fid (which will translate into per open), so that should
> work well for us as well.

Yep, that's why I added state_t to 9P. There's actually a complication when an 
FSAL actually needs both share_fds and lock_fds. I will be looking into that 
some more.

> > Now each FSAL gets to define exactly what an fsal_fd actually is. At
> > the moment I have the open mode in the generic structure, but maybe it
> > can move into the FSAL private fsal_fd.
> >
> > Not all FSALs will use both open and lock fds, and we could provide
> > separate sizes for them so space would only be allocated when
> > necessary (and if zero, a NULL pointer is passed).
> 
> sounds good.
> 
> > For most operations, the object_handle, and both a share_fd and
> > lock_fd are passed. This allows the FSAL to decide exactly which ones
> > it needs (if it needs a generic "thing" for anonymous I/O it can stash
> > a generic fsal_fd in it's object_handle).
> 
> They're passed with what we have and it's left to the FSAL function to open if
> it needs something?
> One of the problem we have at the moment in VFS is fstat() racing on the
> "generic thing", which can be closed/open in other threads.
> Do we leave it up to FSALs to protect their generic bits then ? (since we 
> can't
> know which FSAL call will use which bit, doing locking ourselves will have to
> be too much for most)

Note the FSAL_VFS fstat race has been resolved (by protecting the fd inside the 
FSAL - I plan to continue this migration, allow the FSAL to protect it's file 
descriptors or whatever they are). And yes, it's up to the FSAL when it 
actually needs to open something.

Note that lock_fds can get left open longer than necessary, particularly in NFS 
v4.0 since there isn't a way for the client to indicate it's done with the lock 
stateid (for NFS v3 the CURRENT code will result in a close of the lock_fd 
anytime the lock owner drops to zero locks on a file - I think we may want to 
proactively allow for keeping the state_t around a bit longer and thus allow 
the FSAL the option of also keeping the fd (or whatever) open longer).

> > The benefit of this interface is that the FSAL can leverage cache
> > inode AVL tree and SAL hash tables without making upcalls (that would
> > be fraught with locking issues) or duplicating hash tables in order to
> > store information entirely separately. It also may open possibilities
> > to better hinting between the layers so garbage collection can be
> improved.
> 
> yay. (just need to make sure we "close" anything that has been left open on
> GC, so need a common level flag to say it's used maybe?)

The fsal_fd that are attached to state_t have a pretty defined lifetime. The 
global fsal_fd attached to the object_handle already has a reasonable mechanism 
in place for managing it's lifetime, though we might want to move that 
man

Re: [Nfs-ganesha-devel] Multiple-fd work

[Frank Filz]

> -Original Message-
> From: Daniel Gryniewicz [mailto:d...@redhat.com]
> Sent: Tuesday, July 28, 2015 10:42 AM
> To: nfs-ganesha-devel@lists.sourceforge.net
> Subject: Re: [Nfs-ganesha-devel] Multiple-fd work
> 
> On 07/27/2015 12:33 PM, Frank Filz wrote:
> 
> 
> 
> Is there a reason we can't just pass state_t to the FSAL on the correct
calls?
> That seems the simplest, most straight forward way to do this.

We still need to be able to allocate an FSAL specific structure to the
state_t.

And that is all that the FSAL would actually look at (well, ok, I MIGHT look
at state_type to understand a bit better what it needs to do.

But ultimately, what the fsal cares about is it's "thing".

I'm happy to rename the "thing" something other than fsal_fd. How about
fsal_state_private or something like that?

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Multiple-fd work

[Frank Filz]

> The problem is that "fd"s are an internal detail that we do not want leaking
> out into the general server.
> 
> There are several reasons for this adduced in my and Adam's comments in
> gerrit.
> 
> I may be missing something, but what is the generic (non-VFS or few other
> FSAL-specific) concept that is being represented here?  Is it an OPEN
> complex?

>From what I can tell, this is useful to more than just a few FSALs. Now maybe 
>"file descriptor" is not the best choice (since FSAL_PROXY is going to use the 
>"thing" to stash information about stateids from the upstream server (which 
>will be different though perhaps related to Ganesha's stateids)).

It's context to associate with share reservations (NFS 4 OPEN, NLM SHARE) and 
lock state. Different FSALs will have different context, but perhaps not all 
FSALs will need the context.

But having a "few" FSALs need an API also isn't a good reason to turn down that 
API.

I am working to make this "thing" as generic as makes sense. If there's some 
FSAL that has needs that I haven't considered, then please share those needs 
rather than shooting down ideas.

Frank

> > > Hi Frank, list.
> > >
> > > Frank Filz wrote on Mon, Jul 27, 2015 at 09:33:54AM -0700:
> > > > FSAL_LUSTRE actually also uses fcntl to get POSIX locks, so it has
> > the
> > > > same issues as FSAL_VFS.
> > >
> > > LUSTRE would actually like one fd per open or equivalent if we can
> > reap them
> > > efficiently, for the same reason as GPFS -- sharing a fd kills
> > readahead
> > > behaviour and lustre needs the client to do readahead and has us
> > disable
> > > readahead disk-side, so ganesha performs quite worse with multiple
> > clients.
> > >
> > > Well, I guess that's close enough to what we're doing anyway.
> >
> > Fds that are associated with NFS 4 OPEN or NFS 3 SHARE will be closed
> > appropriately. If the FSAL didn't need to keep them open, we could
> > enhance the cache inode LRU to be able to consider pinned entries for
> > advisory file close. The FSAL could also try to do something to keep
> > track and I dunno, LRU garbage collection of idle file descriptors
> > might actually belong in the FSAL anyway instead of cache inode.
> >
> > > > Now I don't know about other FSALs, though I wouldn't be surprised
> > if
> > > > at least some other FSALs might benefit from some mechanism to
> > > > associate SOMETHING with each lock owner per file.
> > > >
> > > > So I came up with the idea of the FSAL providing the size of the
> > "thing"
> > > > (which I have currently named fsal_fd, but we can change the name
> > if
> > > > it would make folks feel more comfortable) with each Ganesha
> > stateid.
> > > > And then to bring NFS v3 locks and share reservations into the
> > > > picture, I've made them able to use stateids (well, state_t
> > > > structures), which also cleaned up part of the SAL lock interface
> > > > (since NFS v3 can hide it's "state" value in the state_t and stop
> > overloading
> > > state_t *state...
> > >
> > > 9P has a state_t per fid (which will translate into per open), so
> > that should
> > > work well for us as well.
> >
> > Yep, that's why I added state_t to 9P. There's actually a complication
> > when an FSAL actually needs both share_fds and lock_fds. I will be
> > looking into that some more.
> >
> > > > Now each FSAL gets to define exactly what an fsal_fd actually is.
> > At
> > > > the moment I have the open mode in the generic structure, but
> > maybe it
> > > > can move into the FSAL private fsal_fd.
> > > >
> > > > Not all FSALs will use both open and lock fds, and we could
> > provide
> > > > separate sizes for them so space would only be allocated when
> > > > necessary (and if zero, a NULL pointer is passed).
> > >
> > > sounds good.
> > >
> > > > For most operations, the object_handle, and both a share_fd and
> > > > lock_fd are passed. This allows the FSAL to decide exactly which
> > ones
> > > > it needs (if it needs a generic "thing" for anonymous I/O it can
> > stash
> > > > a generic fsal_fd in it's object_handle).
> > >
> > > They're passed with what we have and it's left to the FSAL function
> > to 

Re: [Nfs-ganesha-devel] Multiple-fd work

[Frank Filz]

> > > The problem is that "fd"s are an internal detail that we do not want
> > leaking
> > > out into the general server.
> > >
> > > There are several reasons for this adduced in my and Adam's comments
> > in
> > > gerrit.
> > >
> > > I may be missing something, but what is the generic (non-VFS or few
> > other
> > > FSAL-specific) concept that is being represented here?  Is it an
> > OPEN
> > > complex?
> >
> > From what I can tell, this is useful to more than just a few FSALs.
> > Now maybe "file descriptor" is not the best choice (since FSAL_PROXY
> > is going to use the "thing" to stash information about stateids from
> > the upstream server (which will be different though perhaps related to
> > Ganesha's stateids)).
> 
> I think well-defining the abstraction is key.  Adam didn't intuit that the 
> issue
> was just one of naming, although I agree, I the name "fd"
> may be distracting.
> 
> But I am more concerned about interfaces.  I share Dan's (and perhaps
> Adam's) intuition that we'd like to unify around a smaller number of objects,
> and in making what the general server is doing more transparent to FSAL,
> when that can make for a cleaner interface (we're not trying to hide state
> from FSAL, but we might be interested in avoiding the need to allocate more
> free-standing blobs.  So I liked Dan's suggestion to pass states to FSAL 
> calls.
> Could we talk more about that idea?

I was avoiding the free standing blob (at least for NFS, 9p it was not so 
easy), so for NFS state_t objects, the fsal_fd is allocated along with the 
state_t.

The FSAL has to be able to indicate how much space it needs.

Yes, we COULD pass the state_t (still needs to allocate some space for FSAL 
somehow) instead of the fsal_fd. The question I have is what in there is of 
value to the FSAL. If there really is something of value, then sure, let's pass 
the state_t. Without something of value though, I'm wary of exposing state_t 
stuff to the FSAL (for one thing it's protected by the state_lock, which the 
FSAL normally doesn't have access to).

However, there is another hitch... When doing an open/create, we don't have a 
cache entry or state_t yet (which currently means fsal_fd is actually something 
that needs to be able to be copied).

> > It's context to associate with share reservations (NFS 4 OPEN, NLM
> > SHARE) and lock state. Different FSALs will have different context,
> > but perhaps not all FSALs will need the context.
> >
> > But having a "few" FSALs need an API also isn't a good reason to turn
> > down that API.
> >
> > I am working to make this "thing" as generic as makes sense. If
> > there's some FSAL that has needs that I haven't considered, then
> > please share those needs rather than shooting down ideas.
> 
> I'm very happy to share needs, but I care about implementation decisions,
> too.

Fair enough. I'm sure even as I go through what I am directly implementing 
there will be changes to the API to improve things. And even once it gets 
checked in, there might be a subsequent round of improvements.

I'd love to understand how other FSALs do or don't fit into this concept, and 
how well. Details of needs can only improve the solution.

Thanks

Frank

> > > > > Hi Frank, list.
> > > > >
> > > > > Frank Filz wrote on Mon, Jul 27, 2015 at 09:33:54AM -0700:
> > > > > > FSAL_LUSTRE actually also uses fcntl to get POSIX locks, so it
> > has
> > > > the
> > > > > > same issues as FSAL_VFS.
> > > > >
> > > > > LUSTRE would actually like one fd per open or equivalent if we
> > can
> > > > reap them
> > > > > efficiently, for the same reason as GPFS -- sharing a fd kills
> > > > readahead
> > > > > behaviour and lustre needs the client to do readahead and has
> > us
> > > > disable
> > > > > readahead disk-side, so ganesha performs quite worse with
> > multiple
> > > > clients.
> > > > >
> > > > > Well, I guess that's close enough to what we're doing anyway.
> > > >
> > > > Fds that are associated with NFS 4 OPEN or NFS 3 SHARE will be
> > closed
> > > > appropriately. If the FSAL didn't need to keep them open, we
> > could
> > > > enhance the cache inode LRU to be able to consider pinned entries
> > for
> > > > advisory file close. The FS

Re: [Nfs-ganesha-devel] Multiple-fd work

[Frank Filz]

> With respect to FSAL_GLUSTER, like FSAL_GPFS, I think we can make use
> multiple-fd support (per OPEN) to support OPEN
> UPGRADE/OPEN_DOWNGRADE for specific NFS clients and to avoid the extra
> UNLOCK requests  which you have mentioned at the end.

The UNLOCK stuff needs the FSAL be able to distinguish locks depending on
lock owner, potentially from the same client.

Say we get this lock sequence:

Owner 1: LOCK read/shared 0-15
Owner 2: LOCK read/shared 0-7
Owner 2: LOCK write/exclusive 32-47
Owner 2: LOCK read/shared 512-1023
Owner 1: LOCK read/shared 256-511
Owner 1: UNLOCK 0-EOF

If the FSAL does not support lock owners, Ganesha has established the
following locks to the FSAL:

Ganesha LOCK read/shared 0-15
Ganesha LOCK write/exclusive 32-47
Ganesha LOCK read/shared 256-1023

So when we get the UNLOCK request, we need to:

Ganesha UNLOCK 8-15
Ganesha UNLOCK 256-511

What Ganesha actually does is:

Ganesha UNLOCK 8-31
Ganesha UNLOCK 48-511
Ganesha UNLOCK 1024-EOF

By supporting lock owners in the FSAL, each of those locks above is
independent, and then when Ganesha passes:

Owner 1 UNLOCK 0-EOF

To the FSAL, only Owner 1's locks are released, and Owner 2's locks remain.

> I could have missed the context. Could you please specify how the fd per
> lock owner per file would be used?

A "thing" per lock owner per file would be used if FSAL_GLUSTER had some
kind of state that it wanted to associate in that way.

FSAL_GPFS, for example, which has it's own mechanism to establish lock
owners would not necessarily need something associated with lock owner and
file, unless it wanted finer grained file descriptors (at least the Linux
client will use one open owner for many/all processes, on the other hand, I
don't know when/if Linux client passes lock stateid on I/O operations).

Frank

> Thanks,
> Soumya
> 
> On 07/27/2015 10:03 PM, Frank Filz wrote:
> > We may need to devote a concall to discussing this work, but I'm going
> > to try a modest length discussion of the approach I'm taking and why.
> >
> > Ultimately, this effort got kicked off due to the stupid POSIX lock
> > behavior which really only impacts FSAL_VFS, but then when we started
> > talking about possibly not forcing a one-to-one mapping between file
> > descriptors and object handles, Marc Eshel suggested he could benefit
> > from file descriptors associated with individual NFS v4 OPENs so that
> > GPFS's I/O prediction could do better. And then Open File Descriptor
> > Locks came along which opens FSAL_VFS up to being able to have a much
> > improved lock interface beyond just being able to dodge the stupid POSIX
> lock behavior.
> >
> > And as I got into thinking I realized, hey, to get full share
> > reservation and lock support in FSAL_PROXY, we need to be able to
> > associate open and lock stateids with Ganesha stateids.
> >
> > So now we have:
> >
> > FSAL_GPFS would like to have a file descriptor per OPEN (well, really
> > per OPEN stateid, tracking OPEN upgrade and OPEN_DOWNGRADE), and
> maybe
> > one per NFS v3 client
> >
> > FSAL_VFS would like to have a file descriptor per lock owner per file.
> >
> > FSAL_PROXY would like to have a stateid per OPEN stateid and LOCK
> > stateid
> >
> > FSAL_LUSTRE actually also uses fcntl to get POSIX locks, so it has the
> > same issues as FSAL_VFS.
> >
> > Now I don't know about other FSALs, though I wouldn't be surprised if
> > at least some other FSALs might benefit from some mechanism to
> > associate SOMETHING with each lock owner per file.
> >
> > So I came up with the idea of the FSAL providing the size of the "thing"
> > (which I have currently named fsal_fd, but we can change the name if
> > it would make folks feel more comfortable) with each Ganesha stateid.
> > And then to bring NFS v3 locks and share reservations into the
> > picture, I've made them able to use stateids (well, state_t
> > structures), which also cleaned up part of the SAL lock interface
> > (since NFS v3 can hide it's "state" value in the state_t and stop
overloading
> state_t *state...
> >
> > Now each FSAL gets to define exactly what an fsal_fd actually is. At
> > the moment I have the open mode in the generic structure, but maybe it
> > can move into the FSAL private fsal_fd.
> >
> > Not all FSALs will use both open and lock fds, and we could provide
> > separate sizes for them so space would only be allocated when
> > necessary (and if zero, a NULL pointer is passed).
> >
> > For most operations, the object_handle, and both a share_fd and
> > lock_fd are passed. This allows the F

Re: [Nfs-ganesha-devel] Multiple-fd work

[Frank Filz]

I have pushed a new version of the patch set.

The new version eliminates the global fsal_fd structure.

Now instead, the upper layers pass a state_t to the new calls (which have
been renamed things like open2).

The FSAL also is used to allocate state_t objects, so it can attach whatever
it needs to the state_t. It is passed the state_type and a possible related
state_t so it can decide what it needs to do. The default allocate_state
method just allocates a basic state_t and fills in the bits known.

There is also a free_state that allows an FSAL to take some action before
freeing the memory for a state_t (such as making sure file descriptors are
closed).

Please have a look at this new API.

Note that the start of the FSAL_VFS implementation is nowhere near complete,
but should help in understanding how the interface will be used.

Thanks

Frank

> -Original Message-
> From: Matt W. Benjamin [mailto:m...@cohortfs.com]
> Sent: Wednesday, July 29, 2015 7:02 AM
> To: Daniel Gryniewicz
> Cc: nfs-ganesha-devel@lists.sourceforge.net
> Subject: Re: [Nfs-ganesha-devel] Multiple-fd work
> 
> i.e., I like that it captures the idea (in multi-fd already) to allocate
all at once,
> and this is how I would have intuited we move to opaque user data.
> 
> I think we can deal with whatever workaround solves locking currently
> required for that object (e.g., Adam's suggestion to call up into SAL
layer in
> some cases), esp. since iirc an eventual step in Dan's MDCACHE work
> involved lock reorganization, and a lot things will likely shake out from
that?
> 
> Matt
> 
> - "Matt W. Benjamin"  wrote:
> 
> > This feels to be on the right track.
> >
> > Matt
> >
> > - "Daniel Gryniewicz"  wrote:
> >
> > > On 07/28/2015 03:51 PM, Frank Filz wrote:
> > > 
> > > >
> > > > I was avoiding the free standing blob (at least for NFS, 9p it
> > was
> > > not so easy), so for NFS state_t objects, the fsal_fd is allocated
> > > along with the state_t.
> > > >
> > > > The FSAL has to be able to indicate how much space it needs.
> > > >
> > > > Yes, we COULD pass the state_t (still needs to allocate some
> > space
> > > for FSAL somehow) instead of the fsal_fd. The question I have is
> > what
> > > in there is of value to the FSAL. If there really is something of
> > > value, then sure, let's pass the state_t. Without something of
> > value
> > > though, I'm wary of exposing state_t stuff to the FSAL (for one
> > thing
> > > it's protected by the state_lock, which the FSAL normally doesn't
> > have
> > > access to).
> > > >
> > > > However, there is another hitch... When doing an open/create, we
> > > don't have a cache entry or state_t yet (which currently means
> > fsal_fd
> > > is actually something that needs to be able to be copied).
> > > >
> > >
> > > In my MDCACHE work, the state_t is completely allocated by the FSAL,
> >
> > > since it has to (potentially) store it as well, if there's no
> > MDCACHE
> > >
> > > layer for that FSAL.  So, it can just layer state_t, like it layers
> >
> > > fsal_obj_handle.  The advantage of this is that it looks and behaves
> >
> > > just like object handles, exports, and other things that the FSAL
> > > already layers.  Under this paradigm, open/create would return the
> > > state_t as an out param anyway.
> > >
> > > If this is interesting, the code to call into the FSAL to get/put
> > the
> > >
> > > state is fairly separable, and can go in soon.
> > >
> > > Dan
> > >
> > >
> > >
> > --
> > 
> > > ___
> > > Nfs-ganesha-devel mailing list
> > > Nfs-ganesha-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >
> > --
> > Matt Benjamin
> > CohortFS, LLC.
> > 315 West Huron Street, Suite 140A
> > Ann Arbor, Michigan 48103
> >
> > http://cohortfs.com
> >
> > tel.  734-761-4689
> > fax.  734-769-8938
> > cel.  734-216-5309
> >
> > --
> >  ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> 
> --
> Matt Benjamin
> CohortFS, LLC.
> 315 West Huron Street, Suite 140A
> Ann Arbor, Michigan 48103
> 
> http://cohortfs.com
> 
> tel.  734-761-4689
> fax.  734-769-8938
> cel.  734-216-5309
> 
>

--
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-13

[Frank Filz]

Branch next

Tag:V2.3-dev-13

Highlights

* FSAL_GLUSTER ACL changes

* cache inode tuning

Signed-off-by: Frank S. Filz 

Contents:

4209a1e Frank S. Filz V2.3-dev-13
885b131 Matt Benjamin cache_inode: improved lookup table tuning
31a09de Matt Benjamin cache_inode: remove unused monster buf constant
55e6c8b Matt Benjamin cache_inode_lru: shift object addr in lru_lane_of
c4a437c Jiffin Tony Thottan FSAL_GLUSTER : Handling errors properly in acl
api's
23014fb Jiffin Tony Thottan FSAL_GLUSTER : removing previous acl
implementation


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] README: Announce Re-Push of V2.3-dev-13

[Frank Filz]

Due to playing around with libntirpc and forgetting that I was not back to
current before cutting the merge this week, I goofed and pushed a branch
with a libntirpc regression. Please use this corrected merge. You may need
to git tag -d V2.3-dev-13 if you had pulled the old branch.

Branch next

Tag:V2.3-dev-13

Highlights

* FSAL_GLUSTER ACL changes

* cache inode tuning

Signed-off-by: Frank S. Filz 

Contents:

e42854d Frank S. Filz V2.3-dev-13
885b131 Matt Benjamin cache_inode: improved lookup table tuning
31a09de Matt Benjamin cache_inode: remove unused monster buf constant
55e6c8b Matt Benjamin cache_inode_lru: shift object addr in lru_lane_of
c4a437c Jiffin Tony Thottan FSAL_GLUSTER : Handling errors properly in acl
api's
23014fb Jiffin Tony Thottan FSAL_GLUSTER : removing previous acl
implementation


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Review requested - lots of patches

[Frank Filz]

I'd like to push most of my patches that lead up to the multiple file
descriptor work.

I will not be pushing the FYI patches yet, and there may be some others that
still need some work, but as many of the rest as I can get in will be really
helpful.

Thanks

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Review requested - lots of patches

[Frank Filz]

> I'd like to push most of my patches that lead up to the multiple file
descriptor
> work.
> 
> I will not be pushing the FYI patches yet, and there may be some others
that
> still need some work, but as many of the rest as I can get in will be
really
> helpful.

Frank smacks himself on the head for asking folks to take a look at patches
that weren't tested...

Now they are tested, well, at least for now they pass the pynfs 4.0 tests. I
need to do some NLM testing.

Note that the FYI patches I don't remotely expect to be runnable right now.

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Moving up Clean_RPC() to the top of do_shutdown().

[Frank Filz]

> On 8/5/15 7:59 AM, GerritHub wrote:
> >>From Jiffin Tony Thottan :
> >
> > Jiffin Tony Thottan has uploaded a new change for review.
> >
> >https://review.gerrithub.io/242232
> >
> > Change subject: Moving up Clean_RPC() to the top of do_shutdown().
> 
> Sadly, that's not going to work
> 
> At the very least, that has to go after nfs_rpc_dispatch_stop(), which
will
> unregister the channels first.  Otherwise, new incoming connections, messy
> conflicts, and crashing.
> 
> I'll ask Adam about delayed_shutdown(), currently the top, and whether
that
> can be moved farther down.
> 
> Frank, what the heck does state_async_shutdown() handle in SAL?

There's an async fridge thread for processing lock grant upcalls and async
call backs to NLM clients that use the _MSG RPC calls (which Apple indeed
uses). For those NLM calls, the client makes an RPC call to the server to
make the request. The server doesn't send a response to the call. Instead,
the server makes an RPC call BACK to the client with the response... (some
misguided thing about DOS machines not being able to multi-task or
something).

Frank


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Announce Push of V2.3-dev-14

[Frank Filz]

Branch next

Tag:V2.3-dev-14

NOTE: This build includes an update to libntirpc. Please make sure you
update your submodule.

Highlights

* libntirpc updates

* Moving up Clean_RPC() to the top of do_shutdown()

* make it possible to disable FSAL_NULL

* make max cached, deleted entries configurable

* A bunch of cleanup and minor bug fixes falling out from multiple-fd
  work

Signed-off-by: Frank S. Filz 

Contents:

6bc853c Frank S. Filz V2.3-dev-14
f66ab58 William Allen Simpson Convert svc_destroy and references to inline
atomics
230dfb3 Allison Henderson Disable heartbeat service for gpfs
5ca600a Jiffin Tony Thottan Moving up Clean_RPC() to the top of
do_shutdown().
2e4ad49 Niels de Vos build: make it possible to disable FSAL_NULL
d9055e0 Matt Benjamin cache_inode: make max cached, deleted entries
configurable
726482a Frank S. Filz Eliminate separate cache_inode_rdwr_plus
53385fc Frank S. Filz If dirent is stale in cache_inode_find_by_name don't
leak ESTALE
0819fa4 Frank S. Filz Move some logic from cache_inode_lookup_impl to
cache_inode_find_by_name
a948839 Frank S. Filz Lock TEST and UNLOCK operations will need a state_t to
pass to FSAL
9e49f49 Frank S. Filz Improve debug in nfs4_state_id.c
f4ea420 Frank S. Filz Add hash of NFS v4 state_t by cache entry/owner
fd7fbb3 Frank S. Filz Don't create an NLM state_t if not found and nsm state
doesn't apply
84fd1d4 Frank S. Filz Remove loop to retry lock during grace period
f556164 Frank S. Filz Remove obsolete accesscheck_support
669bfc7 Frank S. Filz Readability update to SAL
3fd6ed7 Frank S. Filz FSAL_PT doesn't support lock_op and share_op, stop
lying
fe210af Frank S. Filz Strip dead code from FSAL_PT
cc3020e Frank S. Filz Update comments about READ with WRITE_ONLY for RFC
7530 page numbers
410317c Frank S. Filz Fix up cache_inode_get_keyed to always set status
8c60841 Frank S. Filz Fix cache inode LRU refcount leak in
cache_inode_lookup.c
cc90bf3 Frank S. Filz Make posix2fsal_attributes void
27344ff Frank S. Filz Actually allow for one ESTALE per dirent on readdir
ac020de Frank S. Filz Add do_lease_op for delegations calls to FSAL.
cf797c8 Frank S. Filz Only kill entry in cache_inode_refresh_attrs if error
is ESTALE


--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] What are these files, are they useful

[Frank Filz]

In doing some scrubbing for licenses, I'm curious about the following files
and what they are used for?

If any of these can be removed, I think that would be good.

Thanks

Frank

scripts/test_pynfs/test.cd_junction.pynfs
scripts/test_pynfs/test_nfs4_fs_localtions_request.pynfs
scripts/test_pynfs/test_nfs4_mount_request.pynfs
scripts/test_pynfs/test_get_root_entry_rawdev.pynfs
scripts/test_pynfs/test.proxy.pynfs
scripts/test_pynfs/test_get_root_entry_type.pynfs
scripts/test_pynfs/test_get_root_entry_supported_attrs.pynfs
scripts/test_pynfs/test_get_root_entry_all_type_for_pseudofs.pynfs

scripts/test_through_mountpoint/test_rename.sh
scripts/test_through_mountpoint/test_create.sh
scripts/test_through_mountpoint/test_create_ls.sh
scripts/test_through_mountpoint/test_create_rm.sh
scripts/test_through_mountpoint/test_mkdircascade.sh
scripts/test_through_mountpoint/test_rm_stat_readdir.sh
scripts/test_through_mountpoint/test_createrenameunlink.sh
scripts/test_through_mountpoint/test_rename2.sh
scripts/test_through_mountpoint/test_createunlink.sh
scripts/test_through_mountpoint/test_read_write.sh

Also, I think the following Docs files are hopelessly out of date and should
be removed:

Docs/nfs-ganesha-adminguide.pdf
Docs/ganesha_logging.pdf
Docs/Resources.txt
Docs/nfs-ganesha-userguide.rtf
Docs/nfs-ganesha-userguide.pdf
Docs/15to20-porting.txt

Some other files that look hopelessly out of date and not useful
ganesha.el
tools/remove_rpc.pl
scripts/reindenture





--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel