Daniel Gryniewicz wrote on Fri, Jan 12, 2018 at 11:19:27AM -0500: >> As to Lustre, I'm pretty sure the stackable FSAL will work fine. A stacked >> FSAL does have the pointer to the subfsal object, and knows which FSAL is >> the subfsal, so in this case where FSAL_LUSTRE MUST stack on top of FSAL_VFS >> (in fact FSAL_LUSTRE create export could do the stacking of FSAL_VFS >> underneath), there would be no issue of FSAL_LUSTRE looking at the subfsal >> obj_handle, or into the state_t and looking at FSAL_VFS structures. > > Good point, I'd assumed LUSTRE would hard-code it's stacking state, and not > use configuration for it, but it's important to actually state it. In fact, > there's no reason for a user to know there's a VFS in the stack at all.
One of the advantage I was seeing in having LUSTRE be a stackable fsal would be more freedom, e.g. we could stack lustre with our other weird fsals (e.g. shook that got ripped off along with lustre but is still useful for us, and basically does similar checks to lustre but specific to CEA's environment) If we hard-code the whole stack then we lose some flexibility, but anyway, I'm not so much convinced by stacking anymore right now, because... >> As long as we properly document what we are doing, and make sure the >> stacking only works as expected, I don't see anything wrong. It only has to >> be a layering violation if we decide it should be... And if doing it >> carefully as I've advocated keeps it safe, then it isn't a layering >> violation... It might be possible to make it safe, but I believe code complexity kind of outweights that point... It's going to be fairly intricate to do whatever kind of locking VFS does properly (obj_hdl->obj_lock) and even if we do at some point this is going to be badly tested code that most people won't even compile whenever there is changes to VFS (just because lustre headers aren't obvious to install) On the other hand, all this FSAL wants to do is a simple function call on a fd right when VFS uses it, so a few lines wart if we can safely hook in at the right place. I'm not arguing this is theorically impossible, just that looking at facts if we keep the "forkfsal" system for XFS then I'd much rather add lustre there than try to maintain something feeling its way through its subfsal handle's internals.... -- Dominique ------------------------------------------------------------------------------ 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
