Jeffrey Altman
2018-12-06 23:33:10 UTC
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
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