As I am digging more into what actually happens with FSAL_MDCACHE, I am finding some structural issues that are probably best resolved by hastening the migration to the support_ex (multiple-fd) API.
The biggest issue that I see is the disappearance of the content_lock means that the assumptions that open "file descriptors" are protected during the operation of an I/O operation. In fact, even before an I/O operation commences, there are atomicity problems because the code: 1. checks to see if the file is open in an appropriate mode 2. if not, re-open the file in an appropriate mode 3. perform the I/O The code used to: 1. take a read lock on the content_lock 2. check to see if the file is open in an appropriate mode 2a. if not, drop the read lock, take a write lock on the content_lock 2b. check again if the file is open in the appropriate mode 2c. if not, re-open the file in the appropriate mode 3. perform the I/O 4. drop the content_lock One option is that we put the content lock back in, it would have to go into the fsal_obj_handle. The other option is to move to the support_ex API which expects the FSAL to protect open file resources appropriately. The problem with this option is that it requires significant coding effort across all FSALs (though it would also allow each FSAL to determine what is actually necessary for open file management - some might not actually use any resource, at least for anonymous I/O (I/O not associated with state). Another issue is the management of open_fd_count, which is used to pressure the LRU thread to run more frequently to close open files. This count is not well managed now, and additionally is not actually used with the support_ex API. I'd like to propose we work out a mechanism where the FSAL is able to communicate to the MDCACHED stacked above it that it has too many open files and would like the LRU thread to work on addressing that. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
