On 01/12/2018 10:08 AM, Frank Filz wrote:
So, the linux/freebsd split was not something I was considering for
stacking. I
agree, that doesn't match well. But the VFS subfsal API looks like it can
just
go away and be a stack instead. And I certainly would not like to see it
extended.
Yea, I think the subfsal could go away.
The VFS/XFS split is more akin to the linux/freebsd split and probably
should stay.
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 LUSTER 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.
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...
Agreed.
Daniel
------------------------------------------------------------------------------
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
