> Can someone please help me to validate my understading, > > 1. struct state_t : This represents open state for nfsv4 for given object. There > is one instance per open file - PER client. > A: This struct is used to find share_share, state_lock and deligation for given > _owner_. > > 2. struct state_hdl : This maintains state per _file_. > A: There is only one instance of this object, and is shared accross the clients > B: This struct maintains list of locks on that file. > > For FSAL which dont support open file description locks, we still need to > maintain one open descriptor per file accross _all_ the clients. > > With support_ex ops what is correct way to do it? > > As per VFS FSAL code, vfs_locate_state has some code to maintain one struct > accross the process, I am thinking "struct state_hdl" is correct place to have > 'struct vfs_fd' kind to struct to maintain one global file descriptor. (Becase it > will be shared accross all the clients), Though I see "struct state_t" has "struct > vfs_fd" - I think it is for FSAL which support OFD. > > If we append struct vfs_fd to state_hdl there should not be need to allocate > extra space in alloc_state api, and find_fd should always point to global > descriptor from state_hdl struct. or vfs_fd from state_t should always point > to fd from state_hdl. > > OR its just we should not use support_ex api with FSAL which dont support > OFD?
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. 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). 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). 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
