There are places the struct attrlist gets copied, if so, either the referral
needs to be duplicated in that copy, or it needs to be a single entity with a
refcount.
One advantage of adding the referral to the struct attrlist is that MDCACHE
will manage cache life of it.
It may or may not be worth having a separate cache validity bit for it
(advantage of doing that is then 9P and V3 GETATTR won’t need to fetch it.
Also, conceivably we could have a dBUS trigger to invalidate all referral
attributes (on the other hand, without a separate validity bit, that dBUS
command could just invalidate the attributes of any object that had a non-empty
referral, though that would delay when a fs_locations attribute becomes visible
if added to an object that previously didn’t have one…) I think I just talked
myself into a separate validity bit. We will want to be able to tell Ganesha to
refresh fs_locations, it can march through all the cached inodes and invalidate
the fs_locations attribute (whether it was empty or not) thus allowing
dynamically moving a sub-tree.
Frank
From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Thursday, February 8, 2018 9:33 AM
To: Frank Filz <ffilz...@mindspring.com>;
nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
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?
Thanks,
Sriram
From: Frank Filz <ffilz...@mindspring.com <mailto:ffilz...@mindspring.com> >
Date: Thursday, February 8, 2018 at 8:34 PM
To: Sriram Patil <srir...@vmware.com <mailto:srir...@vmware.com> >,
"nfs-ganesha-devel@lists.sourceforge.net
<mailto:nfs-ganesha-devel@lists.sourceforge.net> "
<nfs-ganesha-devel@lists.sourceforge.net
<mailto:nfs-ganesha-devel@lists.sourceforge.net> >
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
anyway).
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…
Frank
From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Wednesday, February 7, 2018 6:06 PM
To: Frank Filz <ffilz...@mindspring.com <mailto:ffilz...@mindspring.com> >;
nfs-ganesha-devel@lists.sourceforge.net
<mailto:nfs-ganesha-devel@lists.sourceforge.net>
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->u.directory.fs_location)
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.
Thanks,
Sriram
From: Frank Filz <ffilz...@mindspring.com <mailto:ffilz...@mindspring.com> >
Date: Thursday, February 8, 2018 at 12:24 AM
To: Sriram Patil <srir...@vmware.com <mailto:srir...@vmware.com> >,
"nfs-ganesha-devel@lists.sourceforge.net
<mailto:nfs-ganesha-devel@lists.sourceforge.net> "
<nfs-ganesha-devel@lists.sourceforge.net
<mailto:nfs-ganesha-devel@lists.sourceforge.net> >
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.
Frank
From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Wednesday, February 7, 2018 7:06 AM
To: nfs-ganesha-devel@lists.sourceforge.net
<mailto:nfs-ganesha-devel@lists.sourceforge.net>
Subject: [Nfs-ganesha-devel] About referrals in FSAL_VFS
Hi,
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?
Thanks,
Sriram
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_sig-2Demail-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient-26utm-5Fterm-3Dicon&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE&m=Sxe5kPESvRQNVvLQpnj-kS5z4dSATNnBt_o68SJnuLY&s=s_mPaRcDDkTp9mXMAwNTKTZszaS01QhJt-O3_yMMzHI&e=>
Virus-free.
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_sig-2Demail-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient-26utm-5Fterm-3Dlink&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE&m=Sxe5kPESvRQNVvLQpnj-kS5z4dSATNnBt_o68SJnuLY&s=4Zf0lAj2J05RO-NKkxDvCVKB4dbMDu8cCIjgzNlL1N8&e=>
www.avast.com
---
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
