> Hi Frank, others, > > Frank Filz wrote on Tue, Jan 09, 2018 at 03:19:46PM -0800: > > All in all, these functions are not a great fit for the FSAL API so > > I'm not sure it would be a good solution. Forcing some of the > > functions into FSAL methods would require some code duplication that > > loses some of the advantage of the mechanism. There would also be a > > question of how things like the file descriptors and fsal_filesystems > > are shared between the main FSAL_ VFS and the underlying stacked FSAL. > > Actually we were thinking of making LUSTRE a stackable FSAL under VFS as > well, so when this was brought up on the phone I thought it was a good idea, > but now I'm reading this I have a more basic question-- is there still any use > for the XFS fsal? > Same question for PANFS, I guess, could we tell if anyone is still using that? > The last commit that was specific to panfs was a license change in 2015... > There have been many likely untested changes (multi-fd, > mdcache...) since... > > > Historically XFS exposed handle functions through libhandle before the > kernel VFS did. Now it looks like both linux and freebsd have a variant to > natively handle that, so we only have one FSAL to build either way with > slightly different guts that can be abstracted as we currently do > transparently. > If it's too much effort to maintain XFS and PANFS and they aren't > used/tested anymore, my vote would be to just rip it out.
If we don't need to support older kernels, or seamless migration (no client unmount), XFS is unnecessary, and in fact has the danger of less testing, though really it's using almost the same mechanism as we use for FreeBSD to change up the system calls, dealing with fsid differences, and differences in exactly how the handle is managed. PANFS should be dead, Panasas chose to go with the FreeBSD kernel NFS server for their NFS implementation. I'm not even sure we haven’t managed to break something on FreeBSD since I last ran it. I know the folks at iXsystems were exploring Ganesha but they have dropped out of active exploration. > Re-LUSTRE, I hadn't given it much practical thought but I think stacking will > work for us. We'd be using pure VFS calls and only add a few hooks around > open mostly, the only trick will be to get the subfsal to give us the opened > fd > somehow so we can do additional checks on it, but if we enforce stacking like > mdcache (e.g. lustre MUST be above VFS) then it should be possible. For such intimate stacking, I see no issue with the stacked FSAL peeking into the underlying FSAL's structures (fsal_obj_handle and file descriptor extension to state_t for what you need). In this case, stacking is being used to create the equivalent of a C++ inheritance (though the way MDCACHE stacks on top would be not so easy to do with C++ inheritance...). > There is one point though, we'd ideally want mdcache>lustre>vfs, so we'd > have to do the stacking manually from C code and not let folks do stacking in > their config. Yea, when we do things like this, we need to manage the stacking carefully. 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
