From: Kaleb Keithley [mailto:kkeithle@redhat.com] FSAL_XFS uses the fcntl that XFS provides instead of open_by_handle_at and name_to_handle_at. Thus it works on kernels too old to have those system calls. XFS offers a library that makes the fcntl calls. There are a few other differences but that's the main difference.

The question is if anyone needs the Lustre specific code that is used to make a separate FSAL_LUSTRE from FSAL_VFS. And then, if anyone needs it, is anyone willing to support the code? I have never used Lustre and could not support anything Lustre specific. Thanks Frank

Thanks for that. One thing that would help is more visibility. Is it possible to make the community calls? Tuesday’s 7:00 AM Pacific Time. Thanks Frank From: Ruben Alcolea [mailto:ruben.crash@gmail.com] Sent: Friday, April 4, 2025 9:54 AM To: Frank Filz <ffilzlnx(a)mindspring.com&gt; Cc: devel(a)lists.nfs-ganesha.org; support(a)lists.nfs-ganesha.org Subject: [NFS-Ganesha-Support] Re: [NFS-Ganesha-Devel] Unsupported FSALs Hi Frank, I’m writing as a member of the SaunaFS <https://github.com/leil-io/saunafs> community to confirm that we rely on the SaunaFS FSAL for our filesystem. However, we have encountered issues preventing us from migrating to the latest stable v6.5, as our test suite for Ganesha currently passes only for v4.4 but not for v6.5 (21 / 23 pass successfully, 2 tests fail). In the coming days, I plan to update our GitHub Actions pipeline to run our test suite for Ganesha v6.5, making the results available to the Ganesha community. As part of the SaunaFS community, we are committed to support SaunaFS FSAL and keep it up to date with the latest API changes. From our team, we would like to contribute to ensure FSAL_SAUNAFS remains supported and compatible with the latest Ganesha versions. Best regards, Rubén El lun, 31 mar 2025 a las 23:04, Frank Filz (<ffilzlnx(a)mindspring.com <mailto:ffilzlnx@mindspring.com> >) escribió: Community, We have a number of FSALs in Ganesha that have no effective support, I’d like to understand who might still be relying on them and if there is anyone who might step up to support them, or whether we can consider removing some on an expedited timeline (normally we declare a FSAL is deprecated in one release, and then remove it in the next). Note that with the magic of git, deleted FSALs could easily be resurrected (though they might not have been updated to match API changes). The risk of not removing unsupported code is first that folks will use code with little or no support and open github issues that cannot effectively be addressed, and that unsupported code may not be properly updated as API changes are made. The following FSALs are suspect: src/FSAL/FSAL_VFS/xfs – this is marginally supported, but could be replaced with plain FSAL_VFS src/FSAL/FSAL_VFS – there is also a Lustre FSAL that is built from this src/FSAL/FSAL_GLUSTER src/FSAL/FSAL_LIZARDFS src/FSAL/FSAL_PROXY_V3 src/FSAL/FSAL_PROXY_V4 src/FSAL/FSAL_KVSFS src/FSAL/FSAL_SAUNAFS Thank for your thoughts Frank Filz _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org>

I should have also mentioned… Please open a github issue with the problems you are having with V6.5. I might have suggestions on what might have gone wrong. Frank From: Ruben Alcolea [mailto:ruben.crash@gmail.com] Sent: Friday, April 4, 2025 9:54 AM To: Frank Filz <ffilzlnx(a)mindspring.com&gt; Cc: devel(a)lists.nfs-ganesha.org; support(a)lists.nfs-ganesha.org Subject: Re: [NFS-Ganesha-Devel] Unsupported FSALs Hi Frank, I’m writing as a member of the SaunaFS <https://github.com/leil-io/saunafs> community to confirm that we rely on the SaunaFS FSAL for our filesystem. However, we have encountered issues preventing us from migrating to the latest stable v6.5, as our test suite for Ganesha currently passes only for v4.4 but not for v6.5 (21 / 23 pass successfully, 2 tests fail). In the coming days, I plan to update our GitHub Actions pipeline to run our test suite for Ganesha v6.5, making the results available to the Ganesha community. As part of the SaunaFS community, we are committed to support SaunaFS FSAL and keep it up to date with the latest API changes. From our team, we would like to contribute to ensure FSAL_SAUNAFS remains supported and compatible with the latest Ganesha versions. Best regards, Rubén El lun, 31 mar 2025 a las 23:04, Frank Filz (<ffilzlnx(a)mindspring.com <mailto:ffilzlnx@mindspring.com> >) escribió: Community, We have a number of FSALs in Ganesha that have no effective support, I’d like to understand who might still be relying on them and if there is anyone who might step up to support them, or whether we can consider removing some on an expedited timeline (normally we declare a FSAL is deprecated in one release, and then remove it in the next). Note that with the magic of git, deleted FSALs could easily be resurrected (though they might not have been updated to match API changes). The risk of not removing unsupported code is first that folks will use code with little or no support and open github issues that cannot effectively be addressed, and that unsupported code may not be properly updated as API changes are made. The following FSALs are suspect: src/FSAL/FSAL_VFS/xfs – this is marginally supported, but could be replaced with plain FSAL_VFS src/FSAL/FSAL_VFS – there is also a Lustre FSAL that is built from this src/FSAL/FSAL_GLUSTER src/FSAL/FSAL_LIZARDFS src/FSAL/FSAL_PROXY_V3 src/FSAL/FSAL_PROXY_V4 src/FSAL/FSAL_KVSFS src/FSAL/FSAL_SAUNAFS Thank for your thoughts Frank Filz _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org>

Hi Frank and community, I wanted to share my perspective on the value of maintaining simpler FSALs like VFS or PROXY_V3. * These FSALs provide a consistent method for reproducing testing failures, which we've found useful in the past <https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1194944/comments/737906... . * They offer new users a straightforward way to begin testing (example <https://github.com/nfs-ganesha/nfs-ganesha/blob/afdc43ff7ae1daa91471bc485...>) and serve as a practical foundation for developing custom FSALs. Should we keep at least one of them? Thanks, Yoni On Sun, Apr 6, 2025 at 1:31 PM Ruben Alcolea <ruben.crash(a)gmail.com&gt; wrote:

Solomon Boulos offered to support the PROXY FSALs, so I will leave them alone. If you would be willing to help support also, that would be a great help. Thanks Frank From: Yoni Couriel [mailto:yonic@google.com] Sent: Monday, April 7, 2025 1:00 AM To: Ruben Alcolea <ruben.crash(a)gmail.com&gt; Cc: Frank Filz <ffilzlnx(a)mindspring.com>; devel(a)lists.nfs-ganesha.org; support(a)lists.nfs-ganesha.org Subject: Re: [NFS-Ganesha-Devel] Re: Unsupported FSALs Hi Frank and community, I wanted to share my perspective on the value of maintaining simpler FSALs like VFS or PROXY_V3. * These FSALs provide a consistent method for reproducing testing failures, which we've found useful in the past <https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1194944/comments/737906... . * They offer new users a straightforward way to begin testing (example <https://github.com/nfs-ganesha/nfs-ganesha/blob/afdc43ff7ae1daa91471bc485... ) and serve as a practical foundation for developing custom FSALs. Should we keep at least one of them? Thanks, Yoni On Sun, Apr 6, 2025 at 1:31 PM Ruben Alcolea <ruben.crash(a)gmail.com <mailto:ruben.crash@gmail.com> > wrote: Thank you for sending the invitation Frank. Following your request, I will open a github issue documenting the problems we have with V6.5. Thank you for your support, Rubén El dom, 6 abr 2025 a las 4:45, Frank Filz (<ffilzlnx(a)mindspring.com <mailto:ffilzlnx@mindspring.com> >) escribió: I should have also mentioned… Please open a github issue with the problems you are having with V6.5. I might have suggestions on what might have gone wrong. Frank From: Ruben Alcolea [mailto:ruben.crash@gmail.com <mailto:ruben.crash@gmail.com> ] Sent: Friday, April 4, 2025 9:54 AM To: Frank Filz <ffilzlnx(a)mindspring.com <mailto:ffilzlnx@mindspring.com> > Cc: devel(a)lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> ; support(a)lists.nfs-ganesha.org <mailto:support@lists.nfs-ganesha.org> Subject: Re: [NFS-Ganesha-Devel] Unsupported FSALs Hi Frank, I’m writing as a member of the SaunaFS <https://github.com/leil-io/saunafs> community to confirm that we rely on the SaunaFS FSAL for our filesystem. However, we have encountered issues preventing us from migrating to the latest stable v6.5, as our test suite for Ganesha currently passes only for v4.4 but not for v6.5 (21 / 23 pass successfully, 2 tests fail). In the coming days, I plan to update our GitHub Actions pipeline to run our test suite for Ganesha v6.5, making the results available to the Ganesha community. As part of the SaunaFS community, we are committed to support SaunaFS FSAL and keep it up to date with the latest API changes. From our team, we would like to contribute to ensure FSAL_SAUNAFS remains supported and compatible with the latest Ganesha versions. Best regards, Rubén El lun, 31 mar 2025 a las 23:04, Frank Filz (<ffilzlnx(a)mindspring.com <mailto:ffilzlnx@mindspring.com> >) escribió: Community, We have a number of FSALs in Ganesha that have no effective support, I’d like to understand who might still be relying on them and if there is anyone who might step up to support them, or whether we can consider removing some on an expedited timeline (normally we declare a FSAL is deprecated in one release, and then remove it in the next). Note that with the magic of git, deleted FSALs could easily be resurrected (though they might not have been updated to match API changes). The risk of not removing unsupported code is first that folks will use code with little or no support and open github issues that cannot effectively be addressed, and that unsupported code may not be properly updated as API changes are made. The following FSALs are suspect: src/FSAL/FSAL_VFS/xfs – this is marginally supported, but could be replaced with plain FSAL_VFS src/FSAL/FSAL_VFS – there is also a Lustre FSAL that is built from this src/FSAL/FSAL_GLUSTER src/FSAL/FSAL_LIZARDFS src/FSAL/FSAL_PROXY_V3 src/FSAL/FSAL_PROXY_V4 src/FSAL/FSAL_KVSFS src/FSAL/FSAL_SAUNAFS Thank for your thoughts Frank Filz _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org> _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org>

Hi Frank, Sorry for the late reply. I saw some discussions about the FSAL_VFS (FSAL_VFS/xfs). Could we keep the FSAL_VFS as the supported label? I thought FSAL_VFS might be beneficial to some home lab users (including me). It was suitable for fast deployment in some scenarios. I am happy to spend some time rechecking the whole VFS code and make this more effective support. Thanks! Frank Filz <ffilzlnx(a)mindspring.com&gt; 於 2025年4月1日 週二 上午5:04寫道：

While our product is Lustre-based, we don't use the HSM feature, which I think is the only thing that FSAL_LUSTRE adds (from memory). From that point of view I wouldn't be too concerned to see the current FSAL_LUSTRE removed. However, if we get some more non-POSIX Lustre features, which is a possibility, then we might (attempt to) bring back an expanded FSAL_LUSTRE. In that case we would commit to supporting it. peace & happiness, martin