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. T
>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_allo
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 makin
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.
Ganesha is LGPL specifically to allow non-FOSS FSALs. However, if the
FSAL itse
> 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
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
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
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 ba
> 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 me
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 cras
>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 grac
>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
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: Wed
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 wh
14 matches
Mail list logo
