> 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. 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... Frank > On 01/09/2018 06:19 PM, Frank Filz wrote: > > I was looking into using stackable FSALs instead of the current > > mechanism for creating FSAL_VFS (Linux), FSAL_VFS (freebsd), and > > FSAL_XFS. The following functions are implemented differently for > > FSAL_VFS and FSAL_XFS > > > > int vfs_fd_to_handle(int fd, struct fsal_filesystem *fs, > > vfs_file_handle_t *fh); > > > > This is only used by lookup_path, ultimately the best thing to do > > would probably be to duplicate the lookup_path code in both under > stacked FSALs. > > > > int vfs_name_to_handle(int atfd, > > struct fsal_filesystem *fs, > > const char *name, > > vfs_file_handle_t *fh); > > > > This could be mapped to the FSAL lookup method. > > > > int vfs_open_by_handle(struct vfs_filesystem *fs, > > vfs_file_handle_t *fh, int openflags, > > fsal_errors_t *fsal_error); > > > > This could be mapped to the FSAL open2 method > > > > int vfs_encode_dummy_handle(vfs_file_handle_t *fh, > > struct fsal_filesystem *fs); > > > > This is used to fabricate an object handle when we cross a filesystem > > mount point into a filesystem not handled by the FSAL. It would > > somehow have to be mapped to lookup, but that overloads the use of > > lookup for vfs_name_to_handle. > > > > bool vfs_is_dummy_handle(vfs_file_handle_t *fh); > > > > This one is really internal to the guts of FSAL_VFS/XFS and has no > > analog in the FSAL API. > > > > bool vfs_valid_handle(struct gsh_buffdesc *desc); > > > > This is called by vfs_check_handle and could maybe be mapped to the > > FSAL wire_to_host method. > > > > int vfs_readlink(struct vfs_fsal_obj_handle *myself, > > fsal_errors_t *fsal_error); > > > > This could be mapped to FSAL readlink method. > > > > int vfs_extract_fsid(vfs_file_handle_t *fh, > > enum fsid_type *fsid_type, > > struct fsal_fsid__ *fsid); > > > > This is also called by vfs_check_handle and maybe more of that > > function could be moved into the FSAL wire_to_host method. > > > > int vfs_get_root_handle(struct vfs_filesystem *vfs_fs, > > struct vfs_fsal_export *exp); > > > > int vfs_re_index(struct vfs_filesystem *vfs_fs, > > struct vfs_fsal_export *exp); > > > > These two are used in the process of claiming filesystems during > > create_export, so perhaps could be mapped to FSAL create_export > method. > > > > 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. > > > > 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 > > > > > ---------------------------------------------------------------------------- -- > 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 ------------------------------------------------------------------------------ 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
