Re: [Nfs-ganesha-devel] Subfsal export

[sriram patil]

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
is long or cryptic.

Thanks,
Sriram

On Fri, Nov 10, 2017 at 6:58 PM, Daniel Gryniewicz <d...@redhat.com> wrote:

> You can do this with a stackable FSAL, since it's on top, not underneath,
> so it can override anything you want.  You can even just put the symlink
> part in your FSAL, and defer everything else so VFS, if you want.
>
> Daniel
>
> On 11/08/2017 03:04 PM, Frank Filz wrote:
>
>> 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 <ffilz...@mindspring.com>
>> *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 <spsrirampa...@gmail.com
>> <mailto:spsrirampa...@gmail.com>> 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" <ffilz...@mindspring.com
>> <mailto:ffilz...@mindspring.com>> 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.
>>  > >

Re: [Nfs-ganesha-devel] Subfsal export

[Daniel Gryniewicz]

You can do this with a stackable FSAL, since it's on top, not 
underneath, so it can override anything you want.  You can even just put 
the symlink part in your FSAL, and defer everything else so VFS, if you 
want.


Daniel

On 11/08/2017 03:04 PM, Frank Filz wrote:
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 <ffilz...@mindspring.com>
*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 <spsrirampa...@gmail.com 
<mailto:spsrirampa...@gmail.com>> 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" <ffilz...@mindspring.com
<mailto:ffilz...@mindspring.com>> 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"
<d...@redhat.com <mailto:d...@redhat.com>
 > > <mailto:d...@redhat.com <mailto:d...@redhat.com>>> 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 conta

Re: [Nfs-ganesha-devel] Subfsal export

[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 <ffilz...@mindspring.com>
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 <spsrirampa...@gmail.com 
<mailto:spsrirampa...@gmail.com> > 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" <ffilz...@mindspring.com 
<mailto:ffilz...@mindspring.com> > 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" <d...@redhat.com 
> > <mailto:d...@redhat.com> 
> > <mailto:d...@redhat.com <mailto:d...@redhat.com> >> 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
> >
> >

Re: [Nfs-ganesha-devel] Subfsal export

[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

[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

[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

Re: [Nfs-ganesha-devel] Subfsal export

[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