> On Wed, Sep 28, 2016 at 10:03 PM, Frank Filz <ffilz...@mindspring.com> > wrote: > > 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? > > > I am using vxfs on RHEL-6.7.
Curious why you want to run 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. > > > My initial try to get it working with similar code as of vfs_locate_state is > failed, FSAL with no OFD and no mdcache is facing problem, But it passed > couple of runs if global state framework is not used. (offcource leaking fd) > also open with O_CREAT|O_RDWR (AND no O_EXCL) failed, It worked later > after commenting > + /* > if (createmode != FSAL_NO_CREATE) > return fsalstat(ERR_FSAL_INVAL, 0); > + */ > I am debugging both above, will update findings. Note that FSAL_VFS will need some work to do byte range locks without OFD locks, and you will have to be very careful to never close any file descriptor from within Ganesha for a file that has range locks (POSIX locks held by a process are dropped when the process closes ANY file descriptor for the file). We will also need to move the lock union code into a separate function that can be used by FSALs. > > Again, I encourage you to share as much as you can. It is hard to give you > the best advice with minimal details. > > Yes, I had started to exploring adding fsal to ganesha code, Trying to > understand legal issue etc. Obviously you will have to consult a lawyer and make your own risk assesement, but the intent of the LGPL licensing is to allow FSALs that interface with proprietary code. 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
