The other way is instead of removing the fs_locations callback from object
ops we can add attrlist as one more parameter to the function and pull the
attrs from mdcache and pass it down to fsal. Fsal can then parse the
strings and fill the fsroot and servers.

On Mon 12 Mar, 2018, 8:02 PM Sriram Patil, <srir...@vmware.com> wrote:

> Some questions about this implementation.
>
>
>
> We should be filling the fs_locations in attrs as part of getattrs now,
> this can be done by subfsal getattrs callback so that subfsals have control
> over the fs_locations. But, with this, we may not require the fs_locations
> callback in the obj_ops. Is ti okay to get rid of the fs_locations callback
> or should I just add a comment mentioning this will be deprecated? It will
> also require changes in the existing FSALs which use the fs_locations
> callback currently. What do you think?
>
>
>
> Thanks,
>
> Sriram
>
>
>
> *From: *Sriram Patil <srir...@vmware.com>
> *Date: *Saturday, March 10, 2018 at 8:30 PM
> *To: *Frank Filz <ffilz...@mindspring.com>, "
> nfs-ganesha-devel@lists.sourceforge.net" <
> nfs-ganesha-devel@lists.sourceforge.net>
> *Subject: *Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
>
>
>
> Okay, sounds good. Will work towards getting this right.
>
>
>
> Thanks,
>
> Sriram
>
>
>
> *From: *Frank Filz <ffilz...@mindspring.com>
> *Date: *Friday, March 9, 2018 at 11:20 PM
> *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
>
>
>
> Hmm, did I sow confusion about fs_locations in attrlist? I think that
> would be the best solution. We do need to work to be careful about tracking
> the validity of different parts of the attrlist, since we don’t necessarily
> want to fetch the fs_locations from the filesystem every time we refresh
> attributes.
>
>
>
> I think with fs_locations being in the attrlist, it becomes much easier to
> have a sub-fsal with different handling.
>
>
> Frank
>
>
>
> *From:* Sriram Patil [mailto:srir...@vmware.com]
> *Sent:* Friday, March 9, 2018 9:09 AM
> *To:* Frank Filz <ffilz...@mindspring.com>;
> nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
>
>
>
> Hi Frank,
>
>
>
> Now that the referral fixes for pynfs are approved (not merged yet), I
> wanted to work on the subfsal layer to extend this to subfsal and allow
> having referral points as desired. As we had discussed before, it would be
> a good idea to store fs locations in the attrlist, but a few days back on
> IRC you mentioned that we do not want to jump onto that as yet. So, I was
> thinking of supporting referrals and fs_locations at subfsal layer a little
> differently which will not involve a lot of changes.
>
>
>
> Currently, the vfs_fsal_obj_handle stores fsroot and fslocations as part
> of directory (hdl->u.directory). I was thinking of moving these out of the
> union and make them first class variable in the structure or the union
> inside it. This way the fsroot and fslocations can be stored for any file
> type, for example a symlink. I will be adding some subfsal callbacks for
> populating and retrieving the fslocation details as discussed before.
>
>
>
> Let me know if this looks like a good thing to do or should we think about
> fslocations in attrlist?
>
>
>
> Thanks,
>
> Sriram
>
>
>
> *From: *Sriram Patil <srir...@vmware.com>
> *Date: *Friday, February 9, 2018 at 10:30 AM
> *To: *Frank Filz <ffilz...@mindspring.com>, "
> nfs-ganesha-devel@lists.sourceforge.net" <
> nfs-ganesha-devel@lists.sourceforge.net>
> *Subject: *Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
>
>
>
> Okay, so there are a bunch of things that we need to do. I will just list
> them down here, let me know if I miss anything.
>
>    1. Fs locations can be moved to attrlist and FSAL can fill it as part
>    of getattr if required
>    2. We need ref counting for fs locations for handling attr copy where
>    multiple objects can hold reference to fs locations
>    3. Have a validity bit for fs locations. Allow a dbus command to
>    invalidate all fs_locations to be able to refresh the locations for dynamic
>    updates
>    4. Add methods/callbacks to subfsal mechanism to allow subfsals to
>    choose how referrals work for them. This should also allow a way to follow
>    the default VFS mechanism
>
>
>
> Thanks,
>
> Sriram
>
>
>
> *From: *Frank Filz <ffilz...@mindspring.com>
> *Date: *Friday, February 9, 2018 at 12:05 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
>
>
>
> 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 <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>
> *Date: *Thursday, February 8, 2018 at 8:34 PM
> *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
>
>
>
> 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 <srir...@vmware.com>]
> *Sent:* Wednesday, February 7, 2018 6:06 PM
> *To:* Frank Filz <ffilz...@mindspring.com>;
> 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>
> *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 <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
>
>
>
> [image: 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
>
------------------------------------------------------------------------------
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

Reply via email to