> Thanks a lot for your answer. I think there is so many things that are not > clear > enough for me about the "global fd" concept.
Yea, it's confusing.... Part of the problem is that we are using the mdcache (formerly cache_inode) layer to manage LRU caches of things for the FSALs. The resources used by FSALs to manage file access (file descriptors, global or per state, or NFS v4.x stateid, or whatever) are obviously things that are FSAL specific. On the other hand, they are also associated with file objects (fsal_obj_handle) which we are caching at a global level and managing with LRU at that global level. So one way to handle it would be to do LRU inside each FSAL for its file resources, but then we have N implementations of LRU... And we could also end up with double management of the cache of objects. However, by separating the file resource LRU from the handle cache LRU, we might actually be able to drive the file resource LRU into the FSALs (using some common code libraries so we don't end up with multiple implementations) since promoting, demoting, and reaping the file resources would be entirely independent of the file object (so long as the file object still exists, but that's fine, if mdcache releases the file object, the FSAL will also clean up its file resources before the file object itself Is freed). > On 10/18/17 15:23, Frank Filz wrote: > >> Trying to solve my problem with using a NFSv3 client on FSAL_PROXY, I > >> looked at how open_fd_count was managed. I have few newbie > questions. > >> > >> 1) fsal_close (src/include/fsal.h) > >> > >> fsal_close is claiming to deal with both support_ex and old cases but it > only > >> call fsal close and no close2 op ? Any explanation ? > > fsal_close only calls close op because it is only used to manage the global > fd. In non-support_ex, the global fd was used for everything, now it is just > used for anonymous I/O. > > > I'm not sure to understand correctly. Does-it mean that in support ex > case the close function must also be coded in addition of close2 ? And > if so, what is the difference between close and close2 ? In new > support_ex case, what part of the job should be done by close, and what > other part of the job must be done by close2 ? Why not simply calling > close2 with a "NULL" state ? Yea, I should have implemented it that way... > What do you mean by "fsal_close is only used to manage the global fd" ? > What exactly is a global fd ? Isn't it a concept only link with the way > some fsals choose to work ? So if it was workable to push the file resource LRU (if it's even necessary) into the FSAL, we might still want some hints as to what is going on in the protocol layer, but maybe the FSAL can just infer such. If so, then we could get rid of the fsal close method and just have the statefull close2 method. > >> 2) open2_by_name (src/FSAL/fsal_helper.c) > >> > >> 2.1) Why management of open_fd_count exists only in the "by name" > open > >> case ? > > This case is to handle NFS v3 CREATE operation which is the only time > fsal_open2 is called on the global fd. > > > What does-it mean "fsal_open2 is called on the global fd" ? There is no > global fd parameter in the fsal_open2 function. Sorry, bad writing there... fsal_open2 when called for NFS v3 CREATE is called without a state, so if the FSAL uses a file resource for the operation, it would use a "global fd". Normally the global fd is kept open in anticipation of subsequent use by the client performing I/O on the file just opened (in a non-exclusive create case, the client might read the possibly already existing data, otherwise, normally we would only expect write I/O since the file was just created). The trick if we push all the file resource management into the FSAL would be how the FSAL decides to manage a file resource in this case. In the case of a non-exclusive create, it would not know about the subsequent failure permission of the check that mdcache, and thus might optimistically keep the file open. I actually don't think that would be an issue since I expect it would be a rare occurrence, and the file resource would eventually be released by the LRU if no other activity happened. > >> 2.2) Why we check if we have a valid state after calling fsal open2 > >> before incrementing open_fd_count ? > >> > >> 2.3) Why do we call fsal close after opening the file ? > > fsal_close is only called if a permission error occurs, and a permission > > check > is only done when the file already existed but was not cached (so MDCACHE > could not do a permission check before opening the file). > > > > Thus a succeseful NFS v3 CREATE will leave the file open. > > Sorry, I didn't pay attention to the above test on permission error. > > And what about the previous question 2.2) > > Why we check if we have a valid state after calling fsal open2 > before incrementing open_fd_count ? open_fd_count only applies to attempting to count file resources in use for stateless operations (i.e. an open global fd in many of the FSALs), so it only applies to a stateless fsal_open2 call (from NFS v3 CREATE). Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
