attrlist changes sound good. I am trying to figure out the necessity of a 
separate cache and ref counts. As far as I see, there will not be multiple 
references to fs_locations (which will be just a string in attrlist).

What do you mean by xattr utility is being added in nfs-utils? Is that 
nfs-utils package? Is it just a package dependency or something else?


From: Frank Filz <>
Date: Thursday, February 8, 2018 at 8:34 PM
To: Sriram Patil <>, 
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

Ok, the additional sub_fsal ops look workable.

For the protocol layer stuff, we need a quick way to check if an object is a 
junction. One option is to resurrect the fsal_obj_handle JUNCTION type. Another 
option is to add fs_locations to struct attrlist and then an FSAL supporting 
referral objects would just set that attribute (reading the xattr for those 
implementations). That would mean the fs_locations attribute is always fetched, 
perhaps slowing down getattrs for all referral objects even if the caller isn’t 
going to trigger use of the referral, but one hopes there aren’t too many 
referrals (and most access, at least via NFS v4, will trigger the fs_locations 

I think I actually like adding fs_locations to struct attrlist (note that it 
will add a 2nd attribute like ACL that probably should be refcounted etc.). The 
consequences of forgetting to check for fs_locations attribute somewhere in 
code will be less than not handling the JUNCTION type.

Interesting, a utility to manage the xattr is being added to nfs-utils…


From: Sriram Patil []
Sent: Wednesday, February 7, 2018 6:06 PM
To: Frank Filz <>;
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS

So, any subfsal for a filesystem which does not support xattrs cannot work with 
the current FSAL_VFS referrals mechanism. Ideally, it would be good to have 
subfsal callbacks, the way we have it for other things in ganesha. It will look 
much better instead of overriding a set of functions declared in subfsal.h. 
But, let’s push this for some other day and keep it open for discussion. I was 
thinking of making this change without doing much changes in the current 
framework. This is what I would like to do,

Add a couple of functions in subfsal.h for allowing subfsals to decide how 
referrals work. For example,

bool vfs_is_referral_handle(struct vfs_fsal_obj_handle *hdl, struct attrlist 
*atrs); - we check for the attributes and file types here to decide whether it 
is a referral

fsal_status_t vfs_fetch_referral_locations(struct vfs_fsal_obj_handle *hdl) – 
read the fs_locations (currently through xattrs) and store them where ever 
desired (currently stored in hdl->

Add fs_locations callback in vfs_subfsal_obj_ops, to allow subfsals manage the 
fs_locations on their own.

Both these methods will have a default implementation in FSAL_VFS. So, a 
subfsal can keep using the current mechanism.

However, this is not sufficient. The directory and sticky bit referral is also 
checked in nfs4_op_getattr and nfs4_op_readdir. Need to figure out how to get 
rid of that.


From: Frank Filz <<>>
Date: Thursday, February 8, 2018 at 12:24 AM
To: Sriram Patil <<>>, 
Subject: RE: [Nfs-ganesha-devel] About referrals in FSAL_VFS

If you could share the details of what you want to do differently we can 
discuss the best way to accomplish that.

After the research on what it would take to eliminate sub-FSAL, it’s clear that 
is here to stay, and extending the sub-FSAL API could be the best solution.


From: Sriram Patil []
Sent: Wednesday, February 7, 2018 7:06 AM
Subject: [Nfs-ganesha-devel] About referrals in FSAL_VFS


I understand that we are not supposed to extend subfsals and should move to 
Stackable FSALs. But, since it is not possible in some cases (e.g. 
open_by_handle is not supported by the kernel), subfsal has to stay.

Currently, the referrals decision is made by FSAL_VFS depending on a specific 
set of attributes and user.fs_location xattr value. If a subfsal wants to 
achieve this with some other mechanism, there is no way to do that in the 
current code. So, I wanted to extend the referrals functionality in FSAL_VFS 
and make it more flexible by allowing subfsal to change the behavior or not 
support referrals at all.

Any thoughts?


[age removed by 


Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Nfs-ganesha-devel mailing list

Reply via email to