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>
Date: Thursday, February 8, 2018 at 12:24 AM
To: Sriram Patil <srir...@vmware.com>,
"nfs-ganesha-devel@lists.sourceforge.net"
<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
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
[mage removed by
sender.]<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.
www.avast.com<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=>
------------------------------------------------------------------------------
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
