Hi Frank, ----- "Frank Filz" <ffilz...@mindspring.com> wrote:
> 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 These are very good points, thanks for sorting through all this. > > One option is that we put the content lock back in, it would have to > go into > the fsal_obj_handle. Right, this works, but it's bad^tm, because Dan's lock streamlining is important for current and future performance, correct semantics for different FSALs--and most important for the user-space FSALs we're most suited for. > > 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). Exactly. I think this is the right option, most aligned with our goals, and the intent of MDCACHE--but it will entail work. > > 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. This makes sense. Can existing upcalls cover some of this? Matt > > Frank > > -- Matt Benjamin CohortFS, LLC. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://cohortfs.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 ------------------------------------------------------------------------------ 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
