In yesterdays conf.-call we spoke about pynfs-errors while running
valgrind.
I spent some time today to find out the reason and I'm afraid that was
a user error (so me).
A good few pynfs-tests go to numeric limits for a standard process
and if ganesha is executed under valgrind those limits are h
On Tue, 2017-09-05 at 05:41 -0400, William Allen Simpson wrote:
> On 9/4/17 6:59 AM, Swen Schillig wrote:
> > On Sat, 2017-09-02 at 00:15 -0400, William Allen Simpson wrote:
> > > On 9/1/17 6:09 PM, Frank Filz wrote:
> > > > Lately, we have been plagued
On Sat, 2017-09-02 at 00:15 -0400, William Allen Simpson wrote:
> On 9/1/17 6:09 PM, Frank Filz wrote:
> > Lately, we have been plagued by a lot of intermittent test
> > failures.
> >
> > I have seen intermittent failures in pynfs WRT14, WRT15, and WRT16.
> > These
> > have not been resolved by th
Hi Frank
I'd prefer to keep it the same day, an hour earlier is fine with me.
If you need to move to another day, friday would suit me best.
Cheers Swen
--
Check out the vibrant tech community on one of the world's most
Frank, Dan.
Consider the following situation.
There are 2 configured exports
exp_id = 10
Path = /gpfs0/V4
Pseudo = /gpfs0/V4
exp_id = 20
Path = /gpfs0/V4/Tom
Pseudo = /gpfs0/V4/Tom
Client A is allowed to access export ID 20
but is not allowed to access export ID 10.
When trying to mount ps
Hi Frank
I think Malahal already talked to you about the above.
Just to describe the situation in detail I provide the call-stack
#0 0x7f895e2755d7 in raise () from /lib64/libc.so.6
#1 0x7f895e276cc8 in abort () from /lib64/libc.so.6
#2 0x004e72a0 in cache_inode_lookup_impl (pa
Hi Frank
while testing some of my patches I figured your commit
65599c645a81edbe8b953cc29ac29978671a11be
broke the ability to mount V4 filesystems on GPFS (ERR_ACCESS).
Haven't had time to look into it yet,
Hopefully you already have a good idea what it could be.
Otherwise I will look into it
On Do, 2017-02-23 at 08:35 -0800, Frank Filz wrote:
> >
> However, don't add state_t to the private fd since the global fd does
> not
> need a state and that would needlessly enlarge every FSAL object
> handle.
>
> Instead make a containing structure:
>
> struct myfsal_state_and_fd {
> str
On Do, 2017-02-23 at 04:40 -0500, William Allen Simpson wrote:
> On 2/23/17 3:43 AM, Swen Schillig wrote:
> >
> > while removing some legacy GPFS code I stumbled over this
> >
> > my_fd = (struct gpfs_fd *)(state + 1);
> >
> > which is probably just
I would
consider the removal of the gpfs_fd-memory by doing a free(state)
a side-effect.
However, I agree that this would already be an improvement with very
little effort.
Swen
> On Thu, Feb 23, 2017 at 2:13 PM, Swen Schillig
> wrote:
> >
> > All
> >
> > while
All
while removing some legacy GPFS code I stumbled over this
my_fd = (struct gpfs_fd *)(state + 1);
which is probably just copied from an early version to all our FSALs.
Since we're still in dev for 2.5 I'd volunteer and "transfer" this
into maybe this
struct state_t {
...
aw, Kaleb is the only one offering deb packages.
So, if that is true why not get it back in and make ganesha officially
available for deb-based distros ?
Is there any (legal) reason not to ?
Swen
>
> On 02/02/2017 09:40 AM, Swen Schillig wrote:
> >
> > On Do, 2017-02-02 at 15:24 +01
On Do, 2017-02-02 at 15:24 +0100, Swen Schillig wrote:
> Frank, Kaleb
>
> Is there a reason why we don't have the ganesha tree prepared to
> build
> packages for Ubuntu ?
>
> Kaleb, I know you're maintaining a separate repository for this,
> but I'm not r
Frank, Kaleb
Is there a reason why we don't have the ganesha tree prepared to build
packages for Ubuntu ?
Kaleb, I know you're maintaining a separate repository for this,
but I'm not really sure why it's part of the ganesha tree?
I've seen a few people being interested in those builds
on our ma
On Di, 2017-01-17 at 08:57 -0500, Daniel Gryniewicz wrote:
> Could you send the log directly to me?
>
> Thanks,
> Daniel
Dan
I guess I have another one for you
Program terminated with signal 11, Segmentation fault.
#0 0x004bb2ac in glist_del (node=0x7f7ce4092af8) at
/usr/src/debug/nfs-
Hi Kaleb
I heard you're the man if it comes to build/package ganesha for
Ubuntu(Debian).
Could you provide some more details on that,
like repo, HowTos, etc.
Thanks in advance for your support.
Cheers Swen.
--
Check o
Swen
>
> 16/01/2017 13:56:16 : epoch 587cb7dc : dhcp-9-244-58-137 :
> ganesha.nfsd-14293[work-26] mdcache_unlink :INODE :DEBUG :unlink i
> returned The directory is not empty
>
> Daniel
>
> On 01/16/2017 08:25 AM, Swen Schillig wrote:
> >
> > Dan
> >
>
On Mo, 2017-01-16 at 14:21 -0500, William Allen Simpson wrote:
> Swen, your other very short patch fixes a problem with closing the
> fd. And that's a good thing. But the underlying problem is that
> we have multiple copies of the fd, and do not know whether it has
> been closed.
>
> I'm thinkin
On Mo, 2017-01-16 at 13:53 -0500, William Allen Simpson wrote:
> Swen, I've been looking at your patch, and it has some good ideas.
> For some odd reason, I awoke at 1:30 am thinking about it, and
> got up and wrote some code.
>
I never intended to give you sleepless nights :-)
> I've taken anoth
Dan
while I was performing some simple tests to validate some of my code,
I stumbled over some possible mdcache issue.
Here's what I'm doing. (ganesha-2.5-dev9)
I create the following directory structure
mkdir -p /home/swen//d/c/def/g/h/i/j/
where /home/swen/ is the mount point for a [V
On Di, 2017-01-10 at 13:29 -0800, Frank Filz wrote:
> I did some testing between having dirent caching and not (Dir_Max
> left
> default, or Dir_Max set to 1):
>
> With 1 files, dirent caching enabled
> real 0m1.940s
> real 0m3.652s
> real 0m2.409s
> real 0m1.968s
> real 0m2.098s
> real
;Matt Benjamin"
> > To: "Daniel Gryniewicz"
> > Cc: "Swen Schillig" , "NFS Ganesha Developers" <
> > nfs-ganesha-devel@lists.sourceforge.net>
> > Sent: Monday, December 12, 2016 9:47:53 AM
> > Subject: Re: [ntirpc] closed PRs
Dan, Matt
Up until recently we had a bunch of PRs for NTIRPC
being tested/investigated.
A few weeks ago they were all closed without being merged or at least
commented why they were closed.
Could you please comment on this and maybe provide some info what your
plans are for those PRs.
Cheers S
s,
>
> Matt
Hi Matt
It is re-pushed , I just didn't create a new PR yet.
I was thinking we should test and review before creating a new PR.
But if you prefer to have a PR right away, I can do that.
Cheers Swen
>
> - Original Message -----
> >
> > From: &
On Di, 2016-09-06 at 16:16 -0400, Matt Benjamin wrote:
> Hi,
>
> inline
>
> - Original Message -
> >
> > From: "Swen Schillig"
> > To: "Matt Benjamin" , "Daniel Gryniewicz" > n...@redhat.com>
> > Cc: "
Matt, Dan.
Could you please have a look at the following code areas and verify
what I think is a refcount issue.
clnt_vc_ncreate2()
{
...
if ((oflags & RPC_DPLX_LKP_OFLAG_ALLOC) || (!rec->hdl.xd)) {
xd = rec->hdl.xd = alloc_x_vc_data();
...
} else {
Has anybody seen the behaviour that if a mounted directory is
viewed from Apple's "finder", one can see all entries from
the top-level directory but cannot see anything level down.
If I try to walk through the mounted tree from a command-line
window(CLI), everything works fine.
Any hint is muc
On Fr, 2016-07-29 at 10:28 -0400, Daniel Gryniewicz wrote:
> Could you characterize the load? It would be very useful for me to
> be
> able to reproduce this.
>
> Frank, this is an assert that non-zero refcount on state_owner_t is >
> 0.
> This seems to me to be a use-after-free, since the ref
On Mo, 2016-07-25 at 10:10 -0400, Kaleb S. KEITHLEY wrote:
> On 07/25/2016 09:52 AM, Swen Schillig wrote:
> >
> > I have a few mem-leak fixes for libntirpc discovered by valgrind.
> >
> > Is there a way I could "upstream" them from within our ganesha repo
&g
I have a few mem-leak fixes for libntirpc discovered by valgrind.
Is there a way I could "upstream" them from within our ganesha repo ?
Sorry if that is already described somewhere else.
Cheers Swen
--
What NetFlow Ana
t;
> Daniel
It is hit.
So, if everyone is happy with it being removed, I'll prepare a patch
tomorrow.
Cheers Swen
>
> On 07/07/2016 03:09 AM, Swen Schillig wrote:
> >
> > Any news anyone ?
> >
> > As I suggested during our last call, how about removing th
Any news anyone ?
As I suggested during our last call, how about removing the assert() as
a quick "fix" ?
At least that's how the same situation is handled in get_state_owner().
Cheers Swen
On Di, 2016-07-05 at 16:59 +0200, Swen Schillig wrote:
> On Di, 2016-07-05 at 0
p;dspbuf, "Invalid owner %p", owner);
LogCrit(COMPONENT_STATE, "Unexpected owner {%s}", str);
assert(ht_owner);
return;
}
>
> On 07/04/2016 04:15 AM, Swen Schillig wrote:
> >
> > I'm struggling with
I'm struggling with an abort triggered by assert(ht_owner) in function
dec_state_owner_ref().
The call path is pretty short but I'm still not getting to the
root cause of the issue.
The call path is
nfs4_op_release_lockowner()
-> create_nfs4_owner()
-> get_state_owner()
On Mo, 2016-06-20 at 10:22 +0200, Niels de Vos wrote:
> On Sat, Jun 18, 2016 at 02:22:03PM +0200, Sven Oehme wrote:
> >
> >
> > Hi,
> >
> > i get several requests from customers to provide a interrupt free
> > export
> > modification command (not just add and remove exports), but
> > add/remove/
would have prevented this event here.
Thanks.
Swen
>
> Swen Schillig [s...@vnet.ibm.com] wrote:
>>
>> On 18.04.2016 14:27, Swen Schillig wrote:
>>> On 18.04.2016 14:08, Daniel Gryniewicz wrote:
>>>> The first, obvious questions is, is the client actually sending t
On 18.04.2016 14:27, Swen Schillig wrote:
>
> On 18.04.2016 14:08, Daniel Gryniewicz wrote:
>> The first, obvious questions is, is the client actually sending this
>> value? Obviously we should sanitize it if they are, but if it's a legit
>> request, that points to
Daniel
>
> On 04/18/2016 07:19 AM, Swen Schillig wrote:
I will try to see if I a tcpdump was collected.
I'm not sure if this could qualify as an error-handling issue,
because with this (ganesha) version such a size is valid.
The problem is we never actually verify
that we have the
This is a re-send because I might have picked the wrong mail-address.
Sorry.
Forwarded Message
Subject:[ganesha 2.2] memory violation due to wrong memcpy size
parameter
Date: Mon, 18 Apr 2016 09:22:04 +0200
From: Swen Schillig
To: supp...@gerritforge.com
I'm currently in the process of preparing some updates to support
a native build / installation of Ganesha for SLES.
Beside the usual differences in packaging (names, paths, etc) I keep
stumbling over
dynamic location gathering versus hardcoded references used in other places.
E.g. (nfs-ganesha.
Does anybody know of some build-in limitation/configuration
which would explain why the ganesha process
is not going beyond 800% CPU usage ?
Thanks
Swen
--
Site24x7 APM Insight: Get Deep Visibility into Application Perf
As requested I reworked the "doxygen/cleanup" patches and split them
into more digestible pieces.
They are now separated into doxygen and minor-cleanup patches.
However, there are situations where one or the other
"code modification" ended up in the "doxygen" patches.
This is usually the case wh
Quiet a few functions do have a return value of the type fsal_status_t
which is basically a struct of two integers.
In a non-error situation the second value is not of any interest and even
if an error occured, the second value is often set to zero.
Therefore, I suggest to turn the status variabl
On Mo, 2015-12-07 at 10:04 -0500, William Allen Simpson wrote:
> Highlighting some details in a separate message. Other things
> were simply ignored.
>
> >> Please don't re-write code for the sake of re-writing it. If you
> >> have a serious improvement to make, propose it.
> > I don't think you
On Mo, 2015-12-07 at 09:11 -0500, William Allen Simpson wrote:
> On 12/7/15 7:05 AM, Swen Schillig wrote:
> > I understood that you dislike the changes I proposed.
> > Maybe you can tell us what your changes would be to improve
> > readability, maintainability and "s
On Sa, 2015-12-05 at 17:20 -0500, William Allen Simpson wrote:
> On 12/4/15 12:36 PM, GerritHub wrote:
> >>From :
> >
> > s...@vnet.ibm.com has uploaded a new change for review.
> >
> >https://review.gerrithub.io/254250
> >
> > Change subject: [CLEANUP] Initial cleanup of file nfs_rpc_dispatche
On Do, 2015-10-29 at 08:44 +0100, Swen Schillig wrote:
> On Mi, 2015-10-28 at 21:33 -0700, Frank Filz wrote:
> > So my question is what allocations do we attempt to recover from? And
> > what does that recovery look like? And how do we make sure Ganesha is
> > actually runnin
On Mi, 2015-10-28 at 11:55 -0700, Frank Filz wrote:
> We have had various discussions over the years as to how to best handle out
> of memory conditions.
>
> In the meantime, our code is littered with attempts to handle the situation,
> however, it is not clear to me these really solve anything. I
On Mi, 2015-10-28 at 21:33 -0700, Frank Filz wrote:
> So my question is what allocations do we attempt to recover from? And
> what does that recovery look like? And how do we make sure Ganesha is
> actually running in a sane way if we do recover? And are we just
> kicking the can to the next alloca
On Fr, 2015-10-23 at 10:42 -0400, William Allen Simpson wrote:
> On 10/23/15 10:33 AM, Malahal Naineni wrote:
> > Totally agree with Dan, IMHO, code clean ups should come before RC
> > releases. We are just about to release ganesha2.3.0. Swen, hold your
> > breath until a week or so!
> >
> And of c
I know, I probably shouldn't come up with my second RFC mail
in a week while being a rookie in the ganesha project.
Anyhow, I'll give it a try.
While doing some code reviews I stumbled over the file nfs_worker_thread.c.
It was quiet hard to follow the code and its purpose
especially for that on
On Mo, 2015-10-19 at 06:54 -0700, Frank Filz wrote:
> > On 10/19/2015 09:35 AM, Daniel Gryniewicz wrote:
> > > On Mon, Oct 19, 2015 at 9:13 AM, Swen Schillig
> > wrote:
> > >> I'm not talking about recovery,
> > >> just about how and where to
t talking about recovery,
just about how and where to end a program.
...and I still believe a log-function is not the right place to that.
>
> On Mon, Oct 19, 2015 at 8:43 AM, Swen Schillig wrote:
> > Recently, I realized, that triggering logging-functions
> > (e.g. LogFata
Recently, I realized, that triggering logging-functions
(e.g. LogFatal()) could end the program.
I think this is wrong.
One can argue that it is alright to exit a program from
a function in contrast to only allow this from main().
But I'm pretty sure that there aren't many projects around where
On Do, 2015-10-08 at 16:10 -0700, Frank Filz wrote:
> This is what I have so far:
>
> https://github.com/ffilz/nfs-ganesha/commits/next
>
> I will consider last minute merge requests up until tomorrow morning. At
> this point, I just need 1 hour or so to re-spin, re-test, and tag.
>
> If you hav
55 matches
Mail list logo
