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<mailto:srir...@vmware.com>>
Date: Friday, February 9, 2018 at 10:30 AM
To: Frank Filz <ffilz...@mindspring.com<mailto:ffilz...@mindspring.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

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<mailto:ffilz...@mindspring.com>>
Date: Friday, February 9, 2018 at 12:05 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

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<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

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

[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

Reply via email to