the operation. With NFS v4 clients, that will virtually
> eliminate global fd usage and for V3 clients will mean the global fd is only
> open for files the client is doing I/O on.
That sounds like a great idea.
Matt
>
> Frank
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron
---
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing lis
not to be the bottleneck your result claims,
and I think it's necessary to understand why.
Matt
On Sun, Mar 25, 2018 at 6:17 PM, Matt Benjamin wrote:
> 1 What is the peak outstanding size of outstanding calls
>
> 1.1 if e.g. > 100k is that correct: as last week, why would a s
1 What is the peak outstanding size of outstanding calls
1.1 if e.g. > 100k is that correct: as last week, why would a sensible
client issue more than e.g. 1000 calls without seeing replies?
1.3 if outstanding calls is <= 1, why can test_rbt retire millions of
duty cycles / s in that scenario
ut I don't think I can or should
on a public mailing list. I won't post further on this or similar
threads.
Matt
On Wed, Mar 14, 2018 at 4:27 PM, William Allen Simpson
wrote:
> On 3/14/18 7:27 AM, Matt Benjamin wrote:
>>
>> Daniel doesn't think you've meas
Daniel doesn't think you've measured much accurately yet, but at least
the effort (if not the discussion) aims to.
On Wed, Mar 14, 2018 at 2:54 AM, William Allen Simpson
wrote:
Matt
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 4
On Tue, Mar 13, 2018 at 2:38 AM, William Allen Simpson
wrote:
> On 3/12/18 6:25 PM, Matt Benjamin wrote:
>>
>> If I understand correctly, we always insert records in xid order, and
>> xid is monotonically increasing by 1. I guess pings might come back
>> in any order,
0003
> version=3 procedure=0): average 39738.1842, total 198690.9208
> rpcping tcp localhost threads=5 count=100 (port=2049 program=13
> version=3 procedure=0): average 39913.1032, total 199565.5161
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
No, you won't.
Matt
On Sun, Mar 11, 2018 at 7:15 AM, William Allen Simpson
wrote:
> On 3/10/18 11:18 AM, Matt Benjamin wrote:
>>
>> Marcus has code that prototypes using gss_iov from mit-krb5 1.1.12. I
>> recall describing this to you in 2013.
>>
> That wou
on vector i-o, as
> it currently requires one big buffer input. This will be awhile.
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-893
g tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
time.
>> > Once the dupreq entries goes to 0, remove the drc from tcp_drc_q and add
>> > it to
>> > tcp_drc_recycle_q. Today, entries added to tcp_drc_recycle_q are cleaned
>> > up
>> > periodically. Same logic should clean up these entries too.
>
s/listinfo/nfs-ganesha-devel
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
My intended meaning, and Daniel's when he articulated the same point
Friday, is that "max such calls/s" -is- meaningful for transports NFS
actually supports, and those are the ones we can compare with other
implementations. I think the raw transport opens up some interesting
paths, b
Hi,
On Tue, Feb 20, 2018 at 8:12 AM, William Allen Simpson
wrote:
> On 2/18/18 2:47 PM, Matt Benjamin wrote:
>>
>> On Fri, Feb 16, 2018 at 11:23 AM, William Allen Simpson
>>>
>>> But the planned 2.7 improvements are mostly throughput related, not IOPS.
>>
is adding 6 ms to every read operation, we have a serious
> problem, and need to profile immediately!
>
That's kind of what our team is doing. I look forward to your work
with rpc-ping-mt.
Matt
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 481
Access_Type = RW;
>}
> }
>
>
>
> Thanks & Regards,
>
> Deepak
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashd
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://
Restating this, the code is unified for tcp v4 and v3. It consults
xid and the checksum, which I think is a correct intent. The
slot-reply cache in 4.1+ is, we hope, the improved mechanism.
Matt
On Tue, Jan 30, 2018 at 9:45 AM, Matt Benjamin wrote:
> I don't think that's t
nt tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listin
-
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.s
el mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
ht
en
> the socket is ready again, it will trigger a new event on the thread waiting
> on the epoll.
>
> Bill, please correct me if I'm wrong.
>
> Daniel
>
>
> On 01/25/2018 09:13 PM, Matt Benjamin wrote:
>>
>> Hmm. We used to handle that ;)
>>
tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nf
-
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-dev
99251940649a91882e8c9f Remove support_ex FSAL
>> method
>> > I069b41f0d497bbbc79fbb2b9dea1149bb3a58475 Assume support_ex in
>> FSAL/fsal_helper.c and include/fsal.h
>> > Id87f54ffe86911604bbcf270ae095c385a04fc25 Remove share counters
>> from
t tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/n
The established plan is to finish async and evaluate.
Matt
On Dec 20, 2017 5:02 AM, "William Allen Simpson" <
william.allen.simp...@gmail.com> wrote:
> DanG has raised an interesting issue about recovery from low memory.
> In Ganesha, we've been assiduously changing NULL checks to assert or
> se
ain what could be
> wrong.
>
> Please let me know your feedback, if I missed out on some optimization or
> analysis.
>
> Thanks,
> Supriti
>
> --
> Supriti Singh
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
>
>
Matt
--
---
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourcef
I've already proposed we remove this. No one is invested in it, I don't
think.
Matt
On Dec 10, 2017 2:38 AM, "William Allen Simpson" <
william.allen.simp...@gmail.com> wrote:
> I've run into another TLS problem. It's been there since tirpc.
>
> Apparently, once upon a time, rpc_createerr was a
t; --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mai
---
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourcefor
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel ma
community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
vel mailing list
>> Nfs-ganesha-devel@lists.sourceforge.net
>> <mailto:Nfs-ganesha-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>> <https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel>
>>
t for file descriptors used for sockets, log files,
>> config files, or random libraries that like to open files...
>
>
> Hmmm... I don't think we can do any kind of checking, if we're not going to
> use ulimit by default, since it depends on which FSALs are in use at any
> given
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@l
esha/commits/V2.5-stable
>
>
>
> Frank
>
>
>
> *From:* Malahal Naineni [mailto:mala...@gmail.com]
> *Sent:* Thursday, August 17, 2017 10:39 AM
> *To:* Frank Filz
> *Cc:* Matt Benjamin ; Soumya Koduri <
> skod...@redhat.com>; nfs-ganesha-devel sourceforg
tt
>
>
>
> Frank
>
>
>
>
>
> From: Malahal Naineni [mailto:mala...@gmail.com]
> Sent: Wednesday, August 16, 2017 9:28 AM
> To: Soumya Koduri
> Cc: Frank Filz ; d...@redhat.com; Matt Benjamin
> ; nfs-ganesha-devel
>
> Subject: Re: [Nfs-ganesha-devel]
Hi,
On Tue, Aug 15, 2017 at 8:42 AM, William Allen Simpson
wrote:
> On 8/14/17 4:32 PM, Malahal Naineni wrote:
>>
>> Hi Matt and Bill, we were able to reproduce this crash very easily with a
>> sleep after closing "fd" . After my fix, things worked fine. The changes are
>> a lot but mostly trivia
Hi Malahal,
This looks like a clean solution for 2.3 and I guess 2.4, to me.
Matt
On Mon, Aug 14, 2017 at 4:32 PM, Malahal Naineni wrote:
> Hi Matt and Bill, we were able to reproduce this crash very easily with a
> sleep after closing "fd" . After my fix, things worked fine. The changes are
>
will do, thanks for posting
Matt
On Mon, Aug 14, 2017 at 4:32 PM, Malahal Naineni wrote:
> Hi Matt and Bill, we were able to reproduce this crash very easily with a
> sleep after closing "fd" . After my fix, things worked fine. The changes are
> a lot but mostly trivial. Appreciate any high leve
yes, this is one of the things I thought we might parameterise
On Fri, Aug 11, 2017 at 11:52 AM, Daniel Gryniewicz wrote:
> Right, this is reaping. I was thinking it was the lane thread. Reaping
> only looks at the single LRU of each queue. We should probably look at some
> small number of eac
It's not supposed to, as presently defined, right (scan resistence)?
Matt
On Fri, Aug 11, 2017 at 11:48 AM, Daniel Gryniewicz wrote:
> On 08/11/2017 09:21 AM, Frank Filz wrote:
>>>
>>> That seems overkill to me. How many strategies would we support (and
>>> test)?
>>>
>>> Part of the problem is
hanged how FDs are handled.
> We need to rethink how LRU should work in that context, I think.
>
> Daniel
>
>
> On 08/10/2017 07:59 PM, Matt Benjamin wrote:
>>
>> I think the particular thresholds of opens and inode count are
>> interacting in a way we'd like
I didn't recall this reached 2.5, independent of the current rework.
(offhand, what branch shows the tree consolidation in 2015?) In any
case though, perhaps we should start from pulling up the ntirpc
experimentally.
Matt
On Fri, Aug 11, 2017 at 8:26 AM, William Allen Simpson
wrote:
> On 8/11/1
I think the particular thresholds of opens and inode count are
interacting in a way we'd like to change. I think it might make sense
to delegate the various decision points to maybe a vector of strategy
functions, letting more varied approaches compete?
Matt
On Thu, Aug 10, 2017 at 7:12 PM, Prad
discussion in #ganesha :)
On Thu, Aug 10, 2017 at 3:55 PM, Malahal Naineni wrote:
> Hi All,
>
> One of our customers reported the following backtrace. The returned
> "rec" seems to be corrupted. Based on oflags, rpc_dplx_lookup_rec() didn't
> allocate the "rec" in this call path. Its refc
does this include the fix for readdir chunking config parsing issue?
I thought that affected 2.5.x
Matt
On Wed, Aug 9, 2017 at 9:55 AM, Daniel Gryniewicz wrote:
> Here's my proposed backports for 2.5.2:
>
> commit 7f2d461277521301a417ca368d3c7656edbfc903
> FSAL_GLUSTER: Reset caller_garray
I do not support dropping UDP. Thanks.
Matt
On Tue, Aug 8, 2017 at 10:34 PM, William Allen Simpson
wrote:
> On 8/8/17 1:58 PM, Daniel Gryniewicz wrote:
>>
>> On 08/08/2017 01:17 PM, William Allen Simpson wrote:
>>>
>>> NSM should be accessible by TCP. Why are we using UDP?
>>>
>>> Is there a d
Hi Bill,
While NFSv3 supports TCP, UDP is also supported.
Matt
On Tue, Aug 8, 2017 at 1:17 PM, William Allen Simpson
wrote:
> Frank, Dominique tracked it down:
>
> #0 0x4e2ea0 in calloc
> (/export/nfs-ganesha/build/MainNFSD/ganesha.nfsd+0x4e2ea0)
> #1 0x5d0447 in gsh_calloc__
> /export/
Correct.
Matt
On Thu, Aug 3, 2017 at 10:44 AM, Daniel Gryniewicz wrote:
> I do not believe it's reorganizing code. I think the code in the first
> section is wrong, and the second version is needed.
>
> Once you've dec'd the refcount, you cannot access the pointer. At that
> point, another th
Critical bugfixes need to go to 2.5-stable, sure, but this is fine for the week.
Matt
On Fri, Jul 28, 2017 at 8:01 PM, Frank Filz wrote:
> So this really is just bug fixes, might as well fast forward V2.5-stable...
>
> Obviously not up to the V2.6-dev-1 CMakeLists.txt commit...
>
> What do folks
On Sun, Jul 23, 2017 at 11:26 AM, William Allen Simpson
wrote:
> On 7/21/17 11:17 AM, Matt Benjamin wrote:
>>
>> As we discussed Wed., I'd like to see something like a msg counter and
>> byte counter that induced switching to the next handle. This seems
>> consis
As we discussed Wed., I'd like to see something like a msg counter and
byte counter that induced switching to the next handle. This seems
consistent w/the front or back queuing idea Dan proposed. The
existing lookahead logic knows when we have reads or writes, but
doesn't know how much we read, w
Hi Mark,
As a matter of fact that is one of a bunch of perf and async/non-blocking
changes being worked on for 2.6 and later releases.
Soumya is the person currently working on gfapi async.
Matt
On Jul 21, 2017 3:43 AM, "gui mark" wrote:
> Hi all (cc maintainers),
>
> We've tried a perfor
Dan and Frank are the chunking experts, but iiuc you're right, dir_max
has no effect when chunking is enabled, and iiuc also yes, the plan is
to retire the old dirent cache in favor of chuking. Frank also has
new commits for pruning the dirent cache via it's LRU list.
regards,
Matt
On Wed, Jul
Hi All,
The compute_readdir_cookie feature was originally cooked up for RGW,
but Frank showed that you could implement it for ext4, and probably
other FSALs. I've been remiss in pushing an implementation, but have
now remedied that (for RGW, of course, this function is very simple),
but didn't wa
world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite
-
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.
-
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.s
Hi,
- Original Message -
> From: "William Allen Simpson"
> To: "Matt Benjamin"
> Cc: "NFS Ganesha Developers"
> Sent: Monday, June 19, 2017 10:03:53 PM
> Subject: Re: [Nfs-ganesha-devel] async dispatch not good
>
> On 6/19/17 3:41
shdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benj
.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite
st exploring; I
assume you are proposing to use recv() with MSG_DONTWAIT?
Matt
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/sla
dm.link/slashdot
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
> --
> Check out the vibra
__
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suit
link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Hu
___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michig
rable. Apparently the actually
observed or theorized issue has to do with not disposing of requests in
invalidated DRCs? That seems to be a special case, no?
Matt
- Original Message -
> From: "Malahal Naineni"
> To: "Satya Prakash GS"
> Cc: &quo
I don't see a complete design proposal here. Can you clarify the fuller
picture of what you're proposing to do?
Matt
- Original Message -
> From: "Satya Prakash GS"
> To: "Matt Benjamin" , "Malahal Naineni"
> ,
> nfs-ganesha-devel@
ould simplify the lock code a lot.
> > If there is a case where this would introduce a race please let me know.
> >
> > Thanks,
> > Satya.
> >
> > --
> > Check out the vibrant tech community on one of the world's most
> &g
t;
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists
.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arb
-
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists
an we just revert the fixups when
> we open dev of the next release?
>
The main issue are changes that adapt FSAL_RGW to use an updated version of our
librgw interface. To date, the changes in any give release have been minor,
usually adding or adjusting the arguments to a well-known operation o
pending
further changes. Need to plumb them back into librgw, too, I'm pretty
sure--thanks for updating here, though.
Thanks!
Matt
> Along the way, I also realized there was a bug in FSAL_RGW...
>
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, M
uses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.
ther hand, it also means that
> even if we dump the dirent cache, a client that doesn't give up, and sends a
> non-zero whence may miss entries that folks feel it should have found.
>
> Thanks
>
> Frank
>
>
Hi,
- Original Message -
> From: "William Allen Simpson"
> To: "Matt Benjamin"
> Cc: d...@redhat.com, nfs-ganesha-devel@lists.sourceforge.net
> Sent: Friday, March 10, 2017 2:21:41 PM
> Subject: Re: [Nfs-ganesha-devel] UDP duplicate cache in both Gane
tuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-
that maybe we can get other FSAL feedback, too.
>
> Is anybody specifically interested in helping design the API?
As the proposer of this idea, I'm interested in seeing experimental prototypes
that help us establish and refine something that works. Let's post running
cod
an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.so
something else that could cause this issue.
> >
> > Thanks,
> > Satya.
>
> --
> Announcing the Oxford Dictionaries API! The API offers world-renowned
>
ne of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-dev
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, S
__
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
ht
Ok. Will try that out.
Matt
- Original Message -
> From: "Daniel Gryniewicz"
> To: "Matt Benjamin" , "NFS Ganesha Developers"
>
> Sent: Monday, January 23, 2017 9:01:52 AM
> Subject: Re: segv in mdc_up_invalidate (synchronous upcall)
&g
Responding to myself, in part:
Looks like fsal_export.super_export "works" but presumes there is one, or at
least would if I can safely decide whether to pass super_export if present? Or
something.
Matt
- Original Message -
> From: "Matt Benjamin"
> T
b3bfd1b0, flags=5)
at
/home/mbenjamin/dev/rgw/nfs-ganesha/src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_up.c:55
55 key.fsal = export->sub_export->fsal;
(gdb) p export
$5 = (struct fsal_export *) 0x74493700
(gdb) p export->sub_export
$6 = (struct fsal_export *) 0x0
--
Ma
g! http://sdm.link/slashdot
> _______
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-deve
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734
t; --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists
gt;
>
>
>
> Thanks,
>
>
>
> Sriram
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
>
;
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Nfs-
More to the point, Swen, are you able to re-open any relevant PRs?
Thanks,
Matt
- Original Message -
> From: "Matt Benjamin"
> To: "Daniel Gryniewicz"
> Cc: "Swen Schillig" , "NFS Ganesha Developers"
>
> Sent: Monday, December
I did not intentionally close PRs.
Matt
- Original Message -
> From: "Daniel Gryniewicz"
> To: "Swen Schillig"
> Cc: "Matt Benjamin" , "NFS Ganesha Developers"
>
> Sent: Monday, December 12, 2016 9:25:59 AM
> Subject: Re: [nti
, and
I'm not certain doing so would be wise.
Am I missing something here?
Matt
--
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103
http://www.redhat.com/en/technologies/storage
tel. 734-821-5101
fax. 734-769-8938
cel. 73
Hi Bill,
- Original Message -
>
> However, my patches are changing the API some more -- in this case
> rather trivially, but future patches will be much more aggressive.
As long as they come through as github PRs (the defined process), we should be
fine.
Matt
--
Matt Ben
1 - 100 of 210 matches
Mail list logo
