Re: [Nfs-ganesha-devel] crash in jemalloc leading to a deadlock.

2017-11-08 Thread Malahal Naineni 
backtrace_symbols_fd() takes the same buffer and size arguments as
backtrace_symbols(), but instead of returning an array of strings to the
caller, it writes the strings, one per line, to the file descriptor fd.
backtrace_symbols_fd() does not call malloc(3), and so can be employed in
situations where the latter function might fail.

On Thu, Nov 9, 2017 at 12:24 AM, Daniel Gryniewicz  wrote:

> Allocating in a backtrace seems like a very bad idea.  If there's ever a
> crash during an allocation, it is guaranteed to deadlock.
>
> Daniel
>
>
> On 11/08/2017 01:43 PM, Pradeep wrote:
>
>> I'm using Ganesha 2.6 dev.12 with jemalloc-3.6.0 and hitting a case
>> where jemalloc seem to be holding a lock and crashing. In Ganesha's
>> gsh_backtrace(), we try to allocate memory and that hangs (ended up in
>> deadlock). Have you seen this before? Perhaps it is a good idea not to
>> allocate memory in backtrace path?
>>
>>
>> #0 0x7f49b51ff1bd in __lll_lock_wait () from /lib64/libpthread.so.0
>> #1 0x7f49b51fad02 in _L_lock_791 () from /lib64/libpthread.so.0
>> #2 0x7f49b51fac08 in pthread_mutex_lock () from /lib64/libpthread.so.0
>> #3 0x7f49b65d12dc in arena_bin_malloc_hard () from
>> /lib64/libjemalloc.so.1
>> #4 0x7f49b65d1516 in je_arena_tcache_fill_small () from
>> /lib64/libjemalloc.so.1
>> #5 0x7f49b65ea6ff in je_tcache_alloc_small_hard () from
>> /lib64/libjemalloc.so.1
>> #6 0x7f49b65ca14f in malloc () from /lib64/libjemalloc.so.1
>> #7 0x7f49b6c5a785 in _dl_scope_free () from
>> /lib64/ld-linux-x86-64.so.2
>> #8 0x7f49b6c55841 in _dl_map_object_deps () from
>> /lib64/ld-linux-x86-64.so.2
>> #9 0x7f49b6c5ba4b in dl_open_worker () from
>> /lib64/ld-linux-x86-64.so.2
>> #10 0x7f49b6c57364 in _dl_catch_error () from
>> /lib64/ld-linux-x86-64.so.2
>> #11 0x7f49b6c5b35b in _dl_open () from /lib64/ld-linux-x86-64.so.2
>> #12 0x7f49b48f5ff2 in do_dlopen () from /lib64/libc.so.6
>> #13 0x7f49b6c57364 in _dl_catch_error () from
>> /lib64/ld-linux-x86-64.so.2
>> #14 0x7f49b48f60b2 in __libc_dlopen_mode () from /lib64/libc.so.6
>> #15 0x7f49b48cf595 in init () from /lib64/libc.so.6
>> #16 0x7f49b51fdbb0 in pthread_once () from /lib64/libpthread.so.0
>> #17 0x7f49b48cf6ac in backtrace () from /lib64/libc.so.6
>> #18 0x0045193d in gsh_backtrace () at
>> /usr/src/debug/nfs-ganesha-2.6-dev.12/MainNFSD/nfs_init.c:228
>> #19 0x004519fe in crash_handler (signo=11,
>> info=0x7f49b155db70, ctx=0x7f49b155da40) at
>> /usr/src/debug/nfs-ganesha-2.6-dev.12/MainNFSD/nfs_init.c:244
>> #20 
>> #21 0x7f49b65d0c61 in arena_purge () from /lib64/libjemalloc.so.1
>> #22 0x7f49b65d218d in je_arena_dalloc_large () from
>> /lib64/libjemalloc.so.1
>>
>> 
>> --
>> 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.sourceforge.net/lists/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
> ___
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/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___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Subfsal export

2017-11-08 Thread Frank Filz 
Yea, in the case of wanting to allow symlink exports, you would need to replace 
the method. I’d be interested in why you want to allow them. That is something 
that actually could be handled by a config or compile option.

 

Frank

 

From: sriram patil [mailto:spsrirampa...@gmail.com] 
Sent: Wednesday, November 8, 2017 10:20 AM
To: Frank Filz 
Cc: d...@redhat.com; nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] Subfsal export

 

Hi,

 

In case of stackable FSALs, what if I want the underlying FSAL behave 
differently. For example, VFS does not allow symlink exports, lookup_path fails 
if we try to export symlink pointing to a directory. There can be such cases 
where I want to defer (very small changes) from the underlying "sub fsal". For 
bypassing some part of the underlying fsal function, is rewriting the function 
the only way?

 

Thanks,

Sriram

 

 

On Wed, Nov 8, 2017 at 11:22 PM, sriram patil  > wrote:

Hmm stackable FSAL sounds like a good option. Let me investigate on that. I was 
mainly going with sub fsal because of xfs.

 

I agree with both of you about pushing FSAL changes to upstream. Let me see if 
I can make that happen.

 

Thanks,

Sriram

 

On 08-Nov-2017 11:03 PM, "Frank Filz"  > wrote:

> You might want to consider a stackable FSAL instead.  FSAL_NULL is a good
> example to start from.  It's much more flexible than sub_fsals for VFS.
If I
> was implementing PanFS now, I'd use a stackable FSAL instead.

Yea, this is a good point. Probably even the XFS/VFS split should be done
with stackable FSAL.

> Ganesha is LGPL specifically to allow non-FOSS FSALs.  However, if the
FSAL
> itself does not require proprietary code, there are many advantages to
open
> sourcing it and getting it upstream.  Not the least is that changes to
APIs and
> the build system will be fixed by the community, so there will be fewer
cases
> of sudden breakage for you to fix.

On top of direct API impacts, it also helps to understand how other FSALs
are using Ganesha so that not only do we not break the API, but don't break
other assumptions that were made. It also is a better platform for
requesting FSAL specific API accommodation (for a recent example, see
compute_readdir_cookie and whence_is_name support that was added for
FSAL_RGW, though added in a generic way so other FSALs might use it).

Frank

> Daniel
>
> On 11/08/2017 10:51 AM, sriram patil wrote:
> > Yes, I am making a new sub fsal. May not push it to upstream because
> > it will not be useful without the whole framework/product. As part of
> > that, I wanted to allocate an export object which has some extra
> > fields, other than the ones in vfs_fsal_export.
> >
> > Also, I hope creating a sub fsal and not making the implementation
> > opensource does not violate any license terms.
> >
> > Thanks,
> > Sriram
> >
> > On 08-Nov-2017 8:19 PM, "Daniel Gryniewicz"  >  
> >  >> wrote:
> >
> > On 11/08/2017 02:41 AM, sriram patil wrote:
> >
> > Hi,
> >
> > In the subfsal framework, I see that subfsals can have their own
> > fsal_obj_handles by implementing vfs_sub_alloc_handle and then
> > use subfsal specific variables using container_of.
> >
> > It does not provide same functionality for fsal_export however.
> > There is no vfs_sub_alloc_export.  vfs_create_export just calls
> > gsh_calloc to allocate vfs_fsal_export, giving no flexibility.
> >
> > PANFS has its own struct panfs_fsal_export but it is not
> > allocated anywhere. It still uses container_of on
> > vfs_fsal_export. This looks like a memory corruption. The last
> > commit in PANFS however is about a year back, not sure if it is
> > actively developed.
> >
> >
> > PANFS is unused and unmaintained.  We keep it building, but that's
it.
> >
> > Considering the above scenario, it makes sense to have
> > vfs_sub_alloc_export to allow allocating the wrapper export
> > object. Any thoughts?
> >
> >
> > This seems like it was a bug in the original implementation for
> > PanFS. It probably should be fixed, but the VFS sub_fsal doesn't
> > need it, so it works for now.
> >
> > Are you making a new sub_fsal?
> >
> > Daniel
> >
> >

--
> > 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 
> >  
> >  >

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: SAL: remove check_clid recovery operation

2017-11-08 Thread GerritHub 
>From Jeff Layton :

Jeff Layton has uploaded this change for review. ( 
https://review.gerrithub.io/386329


Change subject: SAL: remove check_clid recovery operation
..

SAL: remove check_clid recovery operation

These functions are identical in both recovery operations. Unify them
into a static helper function.

Change-Id: Ie3239d5435c5ff2eefa0ad810134b193d6ff9fbc
Signed-off-by: Jeff Layton 
---
M src/SAL/nfs4_recovery.c
M src/SAL/recovery/recovery_fs.c
M src/SAL/recovery/recovery_rados_kv.c
M src/include/sal_functions.h
4 files changed, 14 insertions(+), 30 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/29/386329/1
-- 
To view, visit https://review.gerrithub.io/386329
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ie3239d5435c5ff2eefa0ad810134b193d6ff9fbc
Gerrit-Change-Number: 386329
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton 
--
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.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: SAL: allow grace period to be lifted early if all clients ha...

2017-11-08 Thread GerritHub 
>From Jeff Layton :

Jeff Layton has uploaded this change for review. ( 
https://review.gerrithub.io/386330


Change subject: SAL: allow grace period to be lifted early if all clients have 
sent RECLAIM_COMPLETE
..

SAL: allow grace period to be lifted early if all clients have sent 
RECLAIM_COMPLETE

Keep track of the number of clients on the recovery list, and the number
on the list that have sent a RECLAIM_COMPLETE. v4.0 clients will never
send a RECLAIM_COMPLETE, so when those values are equal we can lift the
grace period immediately.

For now, this ignores v3 altogether. We'll probably want this to let
the grace period run to completion if any v3 SM_NOTIFYs were sent.

Maybe we should just base that on whether any exports have v3 enabled?

Also, this ignores any sort of clustering. We'll eventually need to
define a set of operations around the grace period handling so that
we can handle clustered configurations correctly.

Change-Id: Ie720da438220f7115d4458b4b995753d480d6491
Signed-off-by: Jeff Layton 
---
M src/Protocols/NFS/nfs4_op_reclaim_complete.c
M src/SAL/nfs4_recovery.c
M src/include/sal_data.h
M src/include/sal_functions.h
4 files changed, 57 insertions(+), 5 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/30/386330/1
-- 
To view, visit https://review.gerrithub.io/386330
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ie720da438220f7115d4458b4b995753d480d6491
Gerrit-Change-Number: 386330
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton 
--
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.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] crash in jemalloc leading to a deadlock.

2017-11-08 Thread Daniel Gryniewicz 
Allocating in a backtrace seems like a very bad idea.  If there's ever a 
crash during an allocation, it is guaranteed to deadlock.


Daniel

On 11/08/2017 01:43 PM, Pradeep wrote:

I'm using Ganesha 2.6 dev.12 with jemalloc-3.6.0 and hitting a case
where jemalloc seem to be holding a lock and crashing. In Ganesha's
gsh_backtrace(), we try to allocate memory and that hangs (ended up in
deadlock). Have you seen this before? Perhaps it is a good idea not to
allocate memory in backtrace path?


#0 0x7f49b51ff1bd in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x7f49b51fad02 in _L_lock_791 () from /lib64/libpthread.so.0
#2 0x7f49b51fac08 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x7f49b65d12dc in arena_bin_malloc_hard () from /lib64/libjemalloc.so.1
#4 0x7f49b65d1516 in je_arena_tcache_fill_small () from
/lib64/libjemalloc.so.1
#5 0x7f49b65ea6ff in je_tcache_alloc_small_hard () from
/lib64/libjemalloc.so.1
#6 0x7f49b65ca14f in malloc () from /lib64/libjemalloc.so.1
#7 0x7f49b6c5a785 in _dl_scope_free () from /lib64/ld-linux-x86-64.so.2
#8 0x7f49b6c55841 in _dl_map_object_deps () from /lib64/ld-linux-x86-64.so.2
#9 0x7f49b6c5ba4b in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#10 0x7f49b6c57364 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#11 0x7f49b6c5b35b in _dl_open () from /lib64/ld-linux-x86-64.so.2
#12 0x7f49b48f5ff2 in do_dlopen () from /lib64/libc.so.6
#13 0x7f49b6c57364 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#14 0x7f49b48f60b2 in __libc_dlopen_mode () from /lib64/libc.so.6
#15 0x7f49b48cf595 in init () from /lib64/libc.so.6
#16 0x7f49b51fdbb0 in pthread_once () from /lib64/libpthread.so.0
#17 0x7f49b48cf6ac in backtrace () from /lib64/libc.so.6
#18 0x0045193d in gsh_backtrace () at
/usr/src/debug/nfs-ganesha-2.6-dev.12/MainNFSD/nfs_init.c:228
#19 0x004519fe in crash_handler (signo=11,
info=0x7f49b155db70, ctx=0x7f49b155da40) at
/usr/src/debug/nfs-ganesha-2.6-dev.12/MainNFSD/nfs_init.c:244
#20 
#21 0x7f49b65d0c61 in arena_purge () from /lib64/libjemalloc.so.1
#22 0x7f49b65d218d in je_arena_dalloc_large () from /lib64/libjemalloc.so.1

--
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.sourceforge.net/lists/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
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] crash in jemalloc leading to a deadlock.

2017-11-08 Thread Frank Filz 
> I'm using Ganesha 2.6 dev.12 with jemalloc-3.6.0 and hitting a case where
> jemalloc seem to be holding a lock and crashing. In Ganesha's
> gsh_backtrace(), we try to allocate memory and that hangs (ended up in
> deadlock). Have you seen this before? Perhaps it is a good idea not to
> allocate memory in backtrace path?

Hmm, sadly backtrace_symbols is a library function, and yea, it allocates
memory...

Not sure there's much we can do about that. It would be interesting to
understand what is causing jemalloc to throw a signal. We probably managed
to corrupt memory... You might run under ASAN and see if it highlights
anything.

When we detect out of memory, we abort() which is not catchable and thus no
backtrace, so at least that path is safe...

Frank

> #0 0x7f49b51ff1bd in __lll_lock_wait () from /lib64/libpthread.so.0
> #1 0x7f49b51fad02 in _L_lock_791 () from /lib64/libpthread.so.0
> #2 0x7f49b51fac08 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #3 0x7f49b65d12dc in arena_bin_malloc_hard () from
> /lib64/libjemalloc.so.1
> #4 0x7f49b65d1516 in je_arena_tcache_fill_small () from
> /lib64/libjemalloc.so.1
> #5 0x7f49b65ea6ff in je_tcache_alloc_small_hard () from
> /lib64/libjemalloc.so.1
> #6 0x7f49b65ca14f in malloc () from /lib64/libjemalloc.so.1
> #7 0x7f49b6c5a785 in _dl_scope_free () from
/lib64/ld-linux-x86-64.so.2
> #8 0x7f49b6c55841 in _dl_map_object_deps () from /lib64/ld-linux-x86-
> 64.so.2
> #9 0x7f49b6c5ba4b in dl_open_worker () from /lib64/ld-linux-x86-
> 64.so.2
> #10 0x7f49b6c57364 in _dl_catch_error () from /lib64/ld-linux-x86-
> 64.so.2
> #11 0x7f49b6c5b35b in _dl_open () from /lib64/ld-linux-x86-64.so.2
> #12 0x7f49b48f5ff2 in do_dlopen () from /lib64/libc.so.6
> #13 0x7f49b6c57364 in _dl_catch_error () from /lib64/ld-linux-x86-
> 64.so.2
> #14 0x7f49b48f60b2 in __libc_dlopen_mode () from /lib64/libc.so.6
> #15 0x7f49b48cf595 in init () from /lib64/libc.so.6
> #16 0x7f49b51fdbb0 in pthread_once () from /lib64/libpthread.so.0
> #17 0x7f49b48cf6ac in backtrace () from /lib64/libc.so.6
> #18 0x0045193d in gsh_backtrace () at
> /usr/src/debug/nfs-ganesha-2.6-dev.12/MainNFSD/nfs_init.c:228
> #19 0x004519fe in crash_handler (signo=11, info=0x7f49b155db70,
> ctx=0x7f49b155da40) at
> /usr/src/debug/nfs-ganesha-2.6-dev.12/MainNFSD/nfs_init.c:244
> #20 
> #21 0x7f49b65d0c61 in arena_purge () from /lib64/libjemalloc.so.1
> #22 0x7f49b65d218d in je_arena_dalloc_large () from
> /lib64/libjemalloc.so.1
> 
>

--
> 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.sourceforge.net/lists/listinfo/nfs-ganesha-devel


---
This email has been checked for viruses 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.link/slashdot
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Subfsal export

2017-11-08 Thread sriram patil 
Hi,

In case of stackable FSALs, what if I want the underlying FSAL behave
differently. For example, VFS does not allow symlink exports, lookup_path
fails if we try to export symlink pointing to a directory. There can be
such cases where I want to defer (very small changes) from the underlying
"sub fsal". For bypassing some part of the underlying fsal function, is
rewriting the function the only way?

Thanks,
Sriram


On Wed, Nov 8, 2017 at 11:22 PM, sriram patil 
wrote:

> Hmm stackable FSAL sounds like a good option. Let me investigate on that.
> I was mainly going with sub fsal because of xfs.
>
> I agree with both of you about pushing FSAL changes to upstream. Let me
> see if I can make that happen.
>
> Thanks,
> Sriram
>
> On 08-Nov-2017 11:03 PM, "Frank Filz"  wrote:
>
>> > You might want to consider a stackable FSAL instead.  FSAL_NULL is a
>> good
>> > example to start from.  It's much more flexible than sub_fsals for VFS.
>> If I
>> > was implementing PanFS now, I'd use a stackable FSAL instead.
>>
>> Yea, this is a good point. Probably even the XFS/VFS split should be done
>> with stackable FSAL.
>>
>> > Ganesha is LGPL specifically to allow non-FOSS FSALs.  However, if the
>> FSAL
>> > itself does not require proprietary code, there are many advantages to
>> open
>> > sourcing it and getting it upstream.  Not the least is that changes to
>> APIs and
>> > the build system will be fixed by the community, so there will be fewer
>> cases
>> > of sudden breakage for you to fix.
>>
>> On top of direct API impacts, it also helps to understand how other FSALs
>> are using Ganesha so that not only do we not break the API, but don't
>> break
>> other assumptions that were made. It also is a better platform for
>> requesting FSAL specific API accommodation (for a recent example, see
>> compute_readdir_cookie and whence_is_name support that was added for
>> FSAL_RGW, though added in a generic way so other FSALs might use it).
>>
>> Frank
>>
>> > Daniel
>> >
>> > On 11/08/2017 10:51 AM, sriram patil wrote:
>> > > Yes, I am making a new sub fsal. May not push it to upstream because
>> > > it will not be useful without the whole framework/product. As part of
>> > > that, I wanted to allocate an export object which has some extra
>> > > fields, other than the ones in vfs_fsal_export.
>> > >
>> > > Also, I hope creating a sub fsal and not making the implementation
>> > > opensource does not violate any license terms.
>> > >
>> > > Thanks,
>> > > Sriram
>> > >
>> > > On 08-Nov-2017 8:19 PM, "Daniel Gryniewicz" > > > > wrote:
>> > >
>> > > On 11/08/2017 02:41 AM, sriram patil wrote:
>> > >
>> > > Hi,
>> > >
>> > > In the subfsal framework, I see that subfsals can have their
>> own
>> > > fsal_obj_handles by implementing vfs_sub_alloc_handle and then
>> > > use subfsal specific variables using container_of.
>> > >
>> > > It does not provide same functionality for fsal_export
>> however.
>> > > There is no vfs_sub_alloc_export.  vfs_create_export just
>> calls
>> > > gsh_calloc to allocate vfs_fsal_export, giving no flexibility.
>> > >
>> > > PANFS has its own struct panfs_fsal_export but it is not
>> > > allocated anywhere. It still uses container_of on
>> > > vfs_fsal_export. This looks like a memory corruption. The last
>> > > commit in PANFS however is about a year back, not sure if it
>> is
>> > > actively developed.
>> > >
>> > >
>> > > PANFS is unused and unmaintained.  We keep it building, but that's
>> it.
>> > >
>> > > Considering the above scenario, it makes sense to have
>> > > vfs_sub_alloc_export to allow allocating the wrapper export
>> > > object. Any thoughts?
>> > >
>> > >
>> > > This seems like it was a bug in the original implementation for
>> > > PanFS. It probably should be fixed, but the VFS sub_fsal doesn't
>> > > need it, so it works for now.
>> > >
>> > > Are you making a new sub_fsal?
>> > >
>> > > Daniel
>> > >
>> > >
>> 
>> 
>> --
>> > > 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.sourceforge.net/lists/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
>> >

Re: [Nfs-ganesha-devel] Subfsal export

2017-11-08 Thread sriram patil 
Hmm stackable FSAL sounds like a good option. Let me investigate on that. I
was mainly going with sub fsal because of xfs.

I agree with both of you about pushing FSAL changes to upstream. Let me see
if I can make that happen.

Thanks,
Sriram

On 08-Nov-2017 11:03 PM, "Frank Filz"  wrote:

> > You might want to consider a stackable FSAL instead.  FSAL_NULL is a good
> > example to start from.  It's much more flexible than sub_fsals for VFS.
> If I
> > was implementing PanFS now, I'd use a stackable FSAL instead.
>
> Yea, this is a good point. Probably even the XFS/VFS split should be done
> with stackable FSAL.
>
> > Ganesha is LGPL specifically to allow non-FOSS FSALs.  However, if the
> FSAL
> > itself does not require proprietary code, there are many advantages to
> open
> > sourcing it and getting it upstream.  Not the least is that changes to
> APIs and
> > the build system will be fixed by the community, so there will be fewer
> cases
> > of sudden breakage for you to fix.
>
> On top of direct API impacts, it also helps to understand how other FSALs
> are using Ganesha so that not only do we not break the API, but don't break
> other assumptions that were made. It also is a better platform for
> requesting FSAL specific API accommodation (for a recent example, see
> compute_readdir_cookie and whence_is_name support that was added for
> FSAL_RGW, though added in a generic way so other FSALs might use it).
>
> Frank
>
> > Daniel
> >
> > On 11/08/2017 10:51 AM, sriram patil wrote:
> > > Yes, I am making a new sub fsal. May not push it to upstream because
> > > it will not be useful without the whole framework/product. As part of
> > > that, I wanted to allocate an export object which has some extra
> > > fields, other than the ones in vfs_fsal_export.
> > >
> > > Also, I hope creating a sub fsal and not making the implementation
> > > opensource does not violate any license terms.
> > >
> > > Thanks,
> > > Sriram
> > >
> > > On 08-Nov-2017 8:19 PM, "Daniel Gryniewicz"  > > > wrote:
> > >
> > > On 11/08/2017 02:41 AM, sriram patil wrote:
> > >
> > > Hi,
> > >
> > > In the subfsal framework, I see that subfsals can have their
> own
> > > fsal_obj_handles by implementing vfs_sub_alloc_handle and then
> > > use subfsal specific variables using container_of.
> > >
> > > It does not provide same functionality for fsal_export however.
> > > There is no vfs_sub_alloc_export.  vfs_create_export just calls
> > > gsh_calloc to allocate vfs_fsal_export, giving no flexibility.
> > >
> > > PANFS has its own struct panfs_fsal_export but it is not
> > > allocated anywhere. It still uses container_of on
> > > vfs_fsal_export. This looks like a memory corruption. The last
> > > commit in PANFS however is about a year back, not sure if it is
> > > actively developed.
> > >
> > >
> > > PANFS is unused and unmaintained.  We keep it building, but that's
> it.
> > >
> > > Considering the above scenario, it makes sense to have
> > > vfs_sub_alloc_export to allow allocating the wrapper export
> > > object. Any thoughts?
> > >
> > >
> > > This seems like it was a bug in the original implementation for
> > > PanFS. It probably should be fixed, but the VFS sub_fsal doesn't
> > > need it, so it works for now.
> > >
> > > Are you making a new sub_fsal?
> > >
> > > Daniel
> > >
> > >
> 
> 
> --
> > > 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.sourceforge.net/lists/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
> > ___
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>
>
> ---
> This email has been checked for viruses 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.link/slashdot___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net

Re: [Nfs-ganesha-devel] Subfsal export

2017-11-08 Thread sriram patil 
Yes, I am making a new sub fsal. May not push it to upstream because it
will not be useful without the whole framework/product. As part of that, I
wanted to allocate an export object which has some extra fields, other than
the ones in vfs_fsal_export.

Also, I hope creating a sub fsal and not making the implementation
opensource does not violate any license terms.

Thanks,
Sriram

On 08-Nov-2017 8:19 PM, "Daniel Gryniewicz"  wrote:

> On 11/08/2017 02:41 AM, sriram patil wrote:
>
>> Hi,
>>
>> In the subfsal framework, I see that subfsals can have their own
>> fsal_obj_handles by implementing vfs_sub_alloc_handle and then use subfsal
>> specific variables using container_of.
>>
>> It does not provide same functionality for fsal_export however. There is
>> no vfs_sub_alloc_export.  vfs_create_export just calls gsh_calloc to
>> allocate vfs_fsal_export, giving no flexibility.
>>
>> PANFS has its own struct panfs_fsal_export but it is not allocated
>> anywhere. It still uses container_of on vfs_fsal_export. This looks like a
>> memory corruption. The last commit in PANFS however is about a year back,
>> not sure if it is actively developed.
>>
>
> PANFS is unused and unmaintained.  We keep it building, but that's it.
>
> Considering the above scenario, it makes sense to have
>> vfs_sub_alloc_export to allow allocating the wrapper export object. Any
>> thoughts?
>>
>
> This seems like it was a bug in the original implementation for PanFS. It
> probably should be fixed, but the VFS sub_fsal doesn't need it, so it works
> for now.
>
> Are you making a new sub_fsal?
>
> Daniel
>
> 
> --
> 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.sourceforge.net/lists/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___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Lower message log level for a non-existent user

2017-11-08 Thread GerritHub 
>From Malahal :

Malahal has uploaded this change for review. ( 
https://review.gerrithub.io/386292


Change subject: Lower message log level for a non-existent user
..

Lower message log level for a non-existent user

uid2grp_allocate_by_uid() logs a message at Event level for non-existent
users.  NFS clients may send requests with non-existent users at the
server, so don't fill the ganesha log with these entries. The message
is now logged at Info level.

Change-Id: Id8249408f920037dc4f10eef44b8647b4661fc83
Signed-off-by: Malahal Naineni 
---
M src/support/nfs_creds.c
M src/support/uid2grp.c
2 files changed, 3 insertions(+), 3 deletions(-)



  git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha 
refs/changes/92/386292/1
-- 
To view, visit https://review.gerrithub.io/386292
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Id8249408f920037dc4f10eef44b8647b4661fc83
Gerrit-Change-Number: 386292
Gerrit-PatchSet: 1
Gerrit-Owner: Malahal 
--
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.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] Subfsal export

2017-11-08 Thread Daniel Gryniewicz 

On 11/08/2017 02:41 AM, sriram patil wrote:

Hi,

In the subfsal framework, I see that subfsals can have their own 
fsal_obj_handles by implementing vfs_sub_alloc_handle and then use 
subfsal specific variables using container_of.


It does not provide same functionality for fsal_export however. There is 
no vfs_sub_alloc_export.  vfs_create_export just calls gsh_calloc to 
allocate vfs_fsal_export, giving no flexibility.


PANFS has its own struct panfs_fsal_export but it is not allocated 
anywhere. It still uses container_of on vfs_fsal_export. This looks like 
a memory corruption. The last commit in PANFS however is about a year 
back, not sure if it is actively developed.


PANFS is unused and unmaintained.  We keep it building, but that's it.

Considering the above scenario, it makes sense to have 
vfs_sub_alloc_export to allow allocating the wrapper export object. Any 
thoughts?


This seems like it was a bug in the original implementation for PanFS. 
It probably should be fixed, but the VFS sub_fsal doesn't need it, so it 
works for now.


Are you making a new sub_fsal?

Daniel

--
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.sourceforge.net/lists/listinfo/nfs-ganesha-devel