> On Mon, Sep 26, 2016 at 10:10 PM, Frank Filz <ffilz...@mindspring.com> > wrote: > > Is your FSAL able to differentiate lock owners? If your underlying > > filesystem treats all of Ganesha as one lock owner, that will be an > > unfortunate issue since I was hoping to remove the code that supports > > maintaining a union of all range locks to the FSAL. > > > > If it can't be helped, obviously we have to find a way to keep that > > logic still in the system. > > Thanks for asking quesiton, Currently FSAL and filesystem don't have support > for lock owners and we will need code to (May be in > fsak_helper.) to support it. > Please help me understanding this, > For posix filesystems there will be still need to differentiate lock > conflicts for > same owner (even with OFD) and maintain owner + lock information. > Because with fcntl we don't have way to specify owner. > So what part of code you are planing to remove? are you saying this list will > be maintained per owner + OFD in FSAL and hence support for OFD will > become must.
The same lock owner never has conflicts so one file descriptor per owner per file with OFD locks satisfies all the needs. We are planning on separating out the code in SAL that manages the union of all locks. FSALs that have no other way to support lock owners will have to replicate the lock list inside the FSAL and utilize some code to manage the union of all locks. We may provide an untested helper function in FSAL/commonlib.c. What is your environment? It sounds like you will be using FSAL_VFS in some way, but don't have OFD locks. Are you using an older Linux or FreeBSD? > > > > Support_ex can still be used, if you otherwise have no use for some > > kind of resource per owner/per file, support_ex allows you to not > > allocate any additional memory for the state_t, and you could just > > maintain a single "global file descriptor" (or whatever resource you use to > access files). > > > Is this global file descriptor should be maintained in similar sturct like > vfs_locate_state? I expect it to work without mdcache. I have yet to explore all the implications of no MDCACHE. I believe the existence of vfs_locate_state maintains a reference on the fsal_obj_handle, in which case, you can still keep the global fd in the fsal_obj_handle (and presumably you would still want to do that since stateless I/O requests will come into the FSAL call with no pointer to a state_t and you may not want to take the effort of looking up the vfs_locate_state. On the other hand, I'm not sure how the upper layers get an fsal_obj_handle reference in that case... Note that the current vfs_locate_state code is really just a proof of concept and only had minimal testing. > > If we go this way, I think the main thing that would have to change is > > to still call lock_op2() in the no lock owner paths from SAL. > > > > Note that Open File Description Locks are not the only way to allow > > for support_ex in its current incarnation: > > > > FSAL_GLUSTER and FSAL_GPFS use the state_t to pass the void > *lockowner > > to the filesystem. > > > > FSAL_PROXY would have a stateid associated with each state_t. > > > > I would also use this as an opportunity to strongly suggest folks > > working on other FSALs make their code public. When we are making API > > changes, we can really only address the needs of the FSALs we know > about. > > > > Even if your FSAL is in a very primitive state, it could still be > > included in tree (we would just disable it by default in > > CMakeLists.txt, with lots of crime scene tape wrapped around it). Again, I encourage you to share as much as you can. It is hard to give you the best advice with minimal details. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
