Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
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 > > > >
Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
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<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 the
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<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<m
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>, "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
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] 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 a
Re: [Nfs-ganesha-devel] About referrals in FSAL_VFS
Yea, that looks right. Frank From: Sriram Patil [mailto:srir...@vmware.com] Sent: Thursday, February 8, 2018 9:01 PM To: Frank Filz <ffilz...@mindspring.com>; 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 <mai
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] 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 cha
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>; 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
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] 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<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 subfsa
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>; 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=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE=Sxe5kPESvRQNVvLQpnj-kS5z4dSATNnBt_o68SJnuLY=s_mPaRcDDkTp9mXMAwNTKTZszaS01QhJt-O3_yMMzHI=> Virus-free. <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_sig-2Demail-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcam
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] 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=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE=Sxe5kPESvRQNVvLQpnj-kS5z4dSATNnBt_o68SJnuLY=s_mPaRcDDkTp9mXMAwNTKTZszaS01QhJt-O3_yMMzHI=> 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=DwMFaQ=uilaK90D4TOVoH58JNXRgQ=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE=Sxe5kPESvRQNVvLQpnj-kS5z4dSATNnBt_o68SJnuLY=4Zf0lAj2J05RO-NKkxDvCVKB4dbMDu8cCIjgzNlL1N8=> -- 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
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 --- 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
