@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] Subfsal export
Thanks for the help Frank and Daniel. I figured it is much easy to enable
"mount_path_pseudo" and use pseudo path instead of using symlinks. No code
changes required. The sole purpose was to hide the original path because it i
>>
>> 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
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 w
: 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
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
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
> 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
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
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
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
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_expo
11 matches
Mail list logo
