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 > > >
