Gary, As far as I am aware there is no final decision either way with regards to inclusion of kafs in rhel8. There are several components that were not merged into Linux mainline until after the 4.18 kernel on which rhel8.0 is based. These include not only AuriStorFS feature and openafs compatibility enhancements to kafs but the new Linux mount API which provides namespace support that kafs leverages and namespacing for keyrings which is needed for filesystem credential management on behalf of containers.
There is no business case for Red Hat to commit a ten year investment simply to support legacy AFS deployments. The justification for including kafs is to support functionality that will result in new deployments. That functionality requires the new mount API, keyring namespacing, and even some features that have yet to be implemented in AuriStorFS. The door is not closed. David Howells and the AuriStor team continue to fill in the gaps. This week a request was filed to add /afs to the File Hierarchy System (FHS). Inclusion in the FHS is required by some Linux Distributions before a new roof directory can be added to the distribution. Jeffrey Altman > On May 7, 2019, at 1:17 PM, Gary Gatling <gsgat...@ncsu.edu> wrote: > > It looks like Red Hat decided no concerning kafs and RHEL. This makes me sad > since they couldn't even be bothered to tell us... > > [root@localhost ~]# modprobe kafs > modprobe: FATAL: Module kafs not found in directory > /lib/modules/4.18.0-80.el8.x86_64 > [root@localhost ~]# cat /etc/redhat-release > Red Hat Enterprise Linux release 8.0 (Ootpa) > > >> On Thu, Dec 6, 2018 at 6:33 PM Jeffrey Altman <jalt...@auristor.com> wrote: >> To all AuriStorFS licensees and OpenAFS users, >> >> After more than seventeen years of development led by David Howells, the >> Linux kernel now includes a production ready AFS/AuriStorFS client >> (kafs) and RX RPC protocol implementation (AF_RXRPC)[1]. These are not >> add-ons. kafs and af_rxrpc are baked into the mainline kernel. >> >> Jonathan Billings has been building kafs enabled Fedora Core kernels via >> COPR[1] since July[3]. Beginning with the 4.19 kernel, Fedora Core >> kernels now ship with kafs and af_rxrpc enabled. >> >> It was my hope that Red Hat would include kafs and af_rxrpc in RHEL8 >> Beta as an experimental technology. Unfortunately, the RHEL8 Beta >> announced on Nov 15th did not include either. >> >> Thankfully it is not too late to for kafs and af_rxrpc to be added >> before a final release of RHEL8 but RHEL support customers must make the >> case by registering for the RHEL8 Beta[4] and opening a Support Case[5]. >> >> When opening a support case please specify: >> >> Product: Red Hat Enterprise Linux >> Version: 8.0 Beta >> Case Type: Feature / Enhancement Request >> Hostname: hostname of the system on which RHEL8 beta was installed >> Problem >> Statement: Request inclusion of kafs >> Case >> Description; Explain why your organization uses AFS/AuriStorFS in >> addition to RHEL support storage systems and how the >> inclusion of kafs and af_rxrpc in RHEL8 will benefit >> your organization. >> >> It is very important that the Case Description be specific to your >> organization. Each organization's reasons for using AFS/AuriStorFS are >> different just as each organization's use cases are different. >> >> If you are eligible, please attempt to open a support request by >> December 11th. Although this is not a hard deadline, many individuals >> will begin taking end of year vacation time the middle of next week. >> >> Frequently Asked Questions: >> >> 1. Is the kafs kernel module a replacement for the OpenAFS and >> AuriStorFS kernel modules? >> >> The best way to think of kafs is that it is an alternative to the >> AFS/AuriStorFS and OpenAFS clients. When kafs is provided as part of a >> Linux distribution and it is enabled, it is not necessary to install any >> of the OpenAFS or AuriStorFS client packages. >> >> 2. Is kafs compatible with IBM AFS, OpenAFS and AuriStorFS servers? >> >> Yes. kafs is compatible with IBM AFS 3.6 and all versions of OpenAFS >> and AuriStorFS servers. >> >> 3. Does enabling kafs and af_rxrpc in RHEL8 prevent installation of >> AuriStorFS or OpenAFS clients? >> >> No. Not only can the AuriStorFS kernel module be installed on Linux >> kernels built with kafs and af_rxrpc but both AuriStorFS and kafs can be >> enabled at the same time. Runtime choices have to be made to decide >> which will service the /afs mount point, which will use port 7001/udp >> for the callback service, etc. However, there is nothing that prevents >> co-existence. >> >> OpenAFS developers will need to ensure compatibility with the latest >> RHEL kernels and build configurations. It is likely that minor coding >> adjustments will need to be implemented. >> >> 4. How does kafs/af_rxrpc performance compare to OpenAFS and AuriStorFS >> clients? >> >> In many workflows the kafs/af_rxrpc client is faster and more efficient >> than either OpenAFS or AuriStorFS clients. kafs/af_rxrpc are tightly >> integrated into the Linux network stack and virtual file system layer. >> There is significantly less overhead in the network stack (no double >> buffering) and no global locks. Building the Linux kernel from source >> in /afs with kafs is at least 30% faster than the AuriStorFS cache >> manager without encryption. >> >> 5. Are there features that OpenAFS has that kafs does not? >> >> Yes. kafs does not split horizon caching, it does not have an >> equivalent of cache bypass, it does not implement any of the rxdebug or >> xstat_cm statistics collection. Nor does it provide pioctls and there is >> no fs, vos, pts, bos command suite. kafs does not export afs2nfs. >> >> 6. Are there features that AuriStorFS has that kafs does not? >> >> In addition to the items mentioned in the prior answer, kafs does not >> yet support the yfs-rxgk security class and aes256-cts-hmac-sha1-96 or >> aes256-cts-hmac-sha512-384 encryption. O_DIRECT support is not yet >> complete. kafs is a fairly complete AuriStorFS client including support >> for IPv6 and AuriStorFS RPC suites. >> >> 7. Does kafs have capabilities that are implemented in neither OpenAFS >> nor AuriStorS? >> >> kafs auto-mounts each afs volume as a separate device instead of >> treating the entire /afs file namespace as a single device. kafs >> implements speculative file status fetching from directory lookups. >> >> Perhaps more important is what kafs will be able to implement that >> OpenAFS and AuriStorFS cannot due to GPL vs IPL10 license conflicts: >> >> * inotify notification event generation >> * SELinux/Smack label storage >> * better container namespacing >> >> 8. If my organization is happy with OpenAFS and/or AuriStorFS clients, >> why should my organization care? >> >> Out-of-the-box Linux distribution support for accessing the /afs file >> namespace will significantly simplify the lives of end users not to >> mention system administrators and help desk support staff. When kafs is >> distributed as part of the Linux kernel, there can never be a conflict >> between the kernel version and the AFS kernel module since they are one >> and the same. There can never be a delay between the availability of a >> new kernel version and the matching OpenAFS or AuriStorFS kernel module. >> AuriStor promises a new kernel module release within 48 hours of the >> release of a kernel for a supported Linux distribution. With OpenAFS >> there have been many circumstances when the delay has been measured in >> weeks or months. >> >> Organizations that have support contracts with Linux vendors are often >> told that support does not apply when the Linux kernel has been tainted >> by a third-party kernel module. When using kafs, the Linux kernel is >> never tainted. >> >> As part of the Linux kernel source tree, kafs is indirectly supported by >> the entire Linux kernel development community. All of the automated >> testing performed against the mainline kernel is also performed against >> kafs. All kernel interface changes impacting kafs or af_rxrpc must be >> implemented in kafs and af_rxrpc by the developer(s) promoting the >> change. All-in-all kafs and af_rxrpc will receive reviews by a much >> larger community of developers. >> >> Finally, as an out-of-the-box solution, /afs becomes a first class file >> system namespace. As a result, AFS adoption will increase and /afs will >> become accessible on systems that are managed by third-party such as >> those in the cloud. >> >> 9. Is there anything I shouldn't say to Red Hat? >> >> Red Hat is going to make a business decision based upon its evaluation >> of customer needs and their impact on growth of RHEL licensing. If I >> were in their shoes I would not find a request to add support for kafs >> compelling if it were combined with a statement that the requesting >> organization intends to discontinue use of /afs within the next three to >> five years. RHEL8 will have a support lifetime of at least a decade and >> there is little justification to commit new engineering resources to a >> technology that customers believe has no future. >> >> 10. Will AuriStor stop developing its own Linux client? >> >> No. AuriStor will always be able to ship new functionality in its own >> clients first. AuriStor believes that kafs will be the AFS client for >> 99.9% of end users with Linux desktops and servers. The AuriStorFS >> client for Linux will be used by organizations that have special needs >> and highly managed environments. >> >> >> Thanks for your assistance on behalf of the entire AFS/AuriStorFS community. >> >> Jeffrey Altman >> >> >> [1] https://www.infradead.org/~dhowells/kafs/ >> [2] https://copr.fedorainfracloud.org/coprs/jsbillings/kafs/ >> [3] https://lists.openafs.org/pipermail/openafs-info/2018-July/042481.html >> [4] https://developers.redhat.com/rhel8/getrhel8/ >> [5] >> https://access.redhat.com/support/cases/#/case/new?intcmp=hp%7Ca%7Ca3%7Ccase >> >>
smime.p7s
Description: S/MIME cryptographic signature
