[OpenAFS] Red Hat EL Support Customers - Please open a support
case for kafs in RHEL8
Gary Gatling
gsgatlin@ncsu.edu
Tue, 7 May 2019 13:17:16 -0400
--00000000000021223005884f64c6
Content-Type: text/plain; charset="UTF-8"
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 <jaltman@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
>
>
>
--00000000000021223005884f64c6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">It looks like Red Hat decided no concerni=
ng kafs and RHEL. This makes me sad since they couldn't even be bothere=
d to tell us...<div><br></div><div><div>[root@localhost ~]# modprobe kafs</=
div><div>modprobe: FATAL: Module kafs not found in directory /lib/modules/4=
.18.0-80.el8.x86_64</div><div>[root@localhost ~]# cat /etc/redhat-release=
=C2=A0</div><div>Red Hat Enterprise Linux release 8.0 (Ootpa)</div></div><d=
iv><br></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Thu, Dec 6, 2018 at 6:33 PM Jeffrey Altman <<a hre=
f=3D"mailto:jaltman@auristor.com">jaltman@auristor.com</a>> wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">To all AuriStorFS lic=
ensees and OpenAFS users,<br>
<br>
After more than seventeen years of development led by David Howells, the<br=
>
Linux kernel now includes a production ready AFS/AuriStorFS client<br>
(kafs) and RX RPC protocol implementation (AF_RXRPC)[1].=C2=A0 These are no=
t<br>
add-ons.=C2=A0 kafs and af_rxrpc are baked into the mainline kernel.<br>
<br>
Jonathan Billings has been building kafs enabled Fedora Core kernels via<br=
>
COPR[1] since July[3].=C2=A0 Beginning with the 4.19 kernel, Fedora Core<br=
>
kernels now ship with kafs and af_rxrpc enabled.<br>
<br>
It was my hope that Red Hat would include kafs and af_rxrpc in RHEL8<br>
Beta as an experimental technology.=C2=A0 Unfortunately, the RHEL8 Beta<br>
announced on Nov 15th did not include either.<br>
<br>
Thankfully it is not too late to for kafs and af_rxrpc to be added<br>
before a final release of RHEL8 but RHEL support customers must make the<br=
>
case by registering for the RHEL8 Beta[4] and opening a Support Case[5].<br=
>
<br>
When opening a support case please specify:<br>
<br>
=C2=A0Product:=C2=A0 =C2=A0 =C2=A0 Red Hat Enterprise Linux<br>
=C2=A0Version:=C2=A0 =C2=A0 =C2=A0 8.0 Beta<br>
=C2=A0Case Type:=C2=A0 =C2=A0 Feature / Enhancement Request<br>
=C2=A0Hostname:=C2=A0 =C2=A0 =C2=A0hostname of the system on which RHEL8 be=
ta was installed<br>
=C2=A0Problem<br>
=C2=A0Statement:=C2=A0 =C2=A0 Request inclusion of kafs<br>
=C2=A0Case<br>
=C2=A0Description;=C2=A0 Explain why your organization uses AFS/AuriStorFS =
in<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addition to RHEL sup=
port storage systems and how the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inclusion of kafs an=
d af_rxrpc in RHEL8 will benefit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0your organization.<b=
r>
<br>
It is very important that the Case Description be specific to your<br>
organization.=C2=A0 Each organization's reasons for using AFS/AuriStorF=
S are<br>
different just as each organization's use cases are different.<br>
<br>
If you are eligible, please attempt to open a support request by<br>
December 11th.=C2=A0 Although this is not a hard deadline, many individuals=
<br>
will begin taking end of year vacation time the middle of next week.<br>
<br>
Frequently Asked Questions:<br>
<br>
1. Is the kafs kernel module a replacement for the OpenAFS and<br>
AuriStorFS kernel modules?<br>
<br>
The best way to think of kafs is that it is an alternative to the<br>
AFS/AuriStorFS and OpenAFS clients.=C2=A0 When kafs is provided as part of =
a<br>
Linux distribution and it is enabled, it is not necessary to install any<br=
>
of the OpenAFS or AuriStorFS client packages.<br>
<br>
2. Is kafs compatible with IBM AFS, OpenAFS and AuriStorFS servers?<br>
<br>
Yes.=C2=A0 kafs is compatible with IBM AFS 3.6 and all versions of OpenAFS<=
br>
and AuriStorFS servers.<br>
<br>
3. Does enabling kafs and af_rxrpc in RHEL8 prevent installation of<br>
AuriStorFS or OpenAFS clients?<br>
<br>
No.=C2=A0 Not only can the AuriStorFS kernel module be installed on Linux<b=
r>
kernels built with kafs and af_rxrpc but both AuriStorFS and kafs can be<br=
>
enabled at the same time.=C2=A0 Runtime choices have to be made to decide<b=
r>
which will service the /afs mount point, which will use port 7001/udp<br>
for the callback service, etc.=C2=A0 However, there is nothing that prevent=
s<br>
co-existence.<br>
<br>
OpenAFS developers will need to ensure compatibility with the latest<br>
RHEL kernels and build configurations.=C2=A0 It is likely that minor coding=
<br>
adjustments will need to be implemented.<br>
<br>
4. How does kafs/af_rxrpc performance compare to OpenAFS and AuriStorFS<br>
clients?<br>
<br>
In many workflows the kafs/af_rxrpc client is faster and more efficient<br>
than either OpenAFS or AuriStorFS clients.=C2=A0 kafs/af_rxrpc are tightly<=
br>
integrated into the Linux network stack and virtual file system layer.<br>
There is significantly less overhead in the network stack (no double<br>
buffering) and no global locks.=C2=A0 Building the Linux kernel from source=
<br>
in /afs with kafs is at least 30% faster than the AuriStorFS cache<br>
manager without encryption.<br>
<br>
5. Are there features that OpenAFS has that kafs does not?<br>
<br>
Yes.=C2=A0 kafs does not split horizon caching, it does not have an<br>
equivalent of cache bypass, it does not implement any of the rxdebug or<br>
xstat_cm statistics collection. Nor does it provide pioctls and there is<br=
>
no fs, vos, pts, bos command suite.=C2=A0 kafs does not export afs2nfs.<br>
<br>
6. Are there features that AuriStorFS has that kafs does not?<br>
<br>
In addition to the items mentioned in the prior answer, kafs does not<br>
yet support the yfs-rxgk security class and aes256-cts-hmac-sha1-96 or<br>
aes256-cts-hmac-sha512-384 encryption.=C2=A0 O_DIRECT support is not yet<br=
>
complete.=C2=A0 kafs is a fairly complete AuriStorFS client including suppo=
rt<br>
for IPv6 and AuriStorFS RPC suites.<br>
<br>
7. Does kafs have capabilities that are implemented in neither OpenAFS<br>
nor AuriStorS?<br>
<br>
kafs auto-mounts each afs volume as a separate device instead of<br>
treating the entire /afs file namespace as a single device.=C2=A0 kafs<br>
implements speculative file status fetching from directory lookups.<br>
<br>
Perhaps more important is what kafs will be able to implement that<br>
OpenAFS and AuriStorFS cannot due to GPL vs IPL10 license conflicts:<br>
<br>
=C2=A0* inotify notification event generation<br>
=C2=A0* SELinux/Smack label storage<br>
=C2=A0* better container namespacing<br>
<br>
8. If my organization is happy with OpenAFS and/or AuriStorFS clients,<br>
why should my organization care?<br>
<br>
Out-of-the-box Linux distribution support for accessing the /afs file<br>
namespace will significantly simplify the lives of end users not to<br>
mention system administrators and help desk support staff.=C2=A0 When kafs =
is<br>
distributed as part of the Linux kernel, there can never be a conflict<br>
between the kernel version and the AFS kernel module since they are one<br>
and the same.=C2=A0 There can never be a delay between the availability of =
a<br>
new kernel version and the matching OpenAFS or AuriStorFS kernel module.<br=
>
=C2=A0AuriStor promises a new kernel module release within 48 hours of the<=
br>
release of a kernel for a supported Linux distribution.=C2=A0 With OpenAFS<=
br>
there have been many circumstances when the delay has been measured in<br>
weeks or months.<br>
<br>
Organizations that have support contracts with Linux vendors are often<br>
told that support does not apply when the Linux kernel has been tainted<br>
by a third-party kernel module.=C2=A0 When using kafs, the Linux kernel is<=
br>
never tainted.<br>
<br>
As part of the Linux kernel source tree, kafs is indirectly supported by<br=
>
the entire Linux kernel development community.=C2=A0 All of the automated<b=
r>
testing performed against the mainline kernel is also performed against<br>
kafs.=C2=A0 All kernel interface changes impacting kafs or af_rxrpc must be=
<br>
implemented in kafs and af_rxrpc by the developer(s) promoting the<br>
change.=C2=A0 All-in-all kafs and af_rxrpc will receive reviews by a much<b=
r>
larger community of developers.<br>
<br>
Finally, as an out-of-the-box solution, /afs becomes a first class file<br>
system namespace.=C2=A0 As a result, AFS adoption will increase and /afs wi=
ll<br>
become accessible on systems that are managed by third-party such as<br>
those in the cloud.<br>
<br>
9. Is there anything I shouldn't say to Red Hat?<br>
<br>
Red Hat is going to make a business decision based upon its evaluation<br>
of customer needs and their impact on growth of RHEL licensing.=C2=A0 If I<=
br>
were in their shoes I would not find a request to add support for kafs<br>
compelling if it were combined with a statement that the requesting<br>
organization intends to discontinue use of /afs within the next three to<br=
>
five years.=C2=A0 RHEL8 will have a support lifetime of at least a decade a=
nd<br>
there is little justification to commit new engineering resources to a<br>
technology that customers believe has no future.<br>
<br>
10. Will AuriStor stop developing its own Linux client?<br>
<br>
No.=C2=A0 AuriStor will always be able to ship new functionality in its own=
<br>
clients first.=C2=A0 AuriStor believes that kafs will be the AFS client for=
<br>
99.9% of end users with Linux desktops and servers.=C2=A0 =C2=A0The AuriSto=
rFS<br>
client for Linux will be used by organizations that have special needs<br>
and highly managed environments.<br>
<br>
<br>
Thanks for your assistance on behalf of the entire AFS/AuriStorFS community=
.<br>
<br>
Jeffrey Altman<br>
<br>
<br>
[1] <a href=3D"https://www.infradead.org/~dhowells/kafs/" rel=3D"noreferrer=
" target=3D"_blank">https://www.infradead.org/~dhowells/kafs/</a><br>
[2] <a href=3D"https://copr.fedorainfracloud.org/coprs/jsbillings/kafs/" re=
l=3D"noreferrer" target=3D"_blank">https://copr.fedorainfracloud.org/coprs/=
jsbillings/kafs/</a><br>
[3] <a href=3D"https://lists.openafs.org/pipermail/openafs-info/2018-July/0=
42481.html" rel=3D"noreferrer" target=3D"_blank">https://lists.openafs.org/=
pipermail/openafs-info/2018-July/042481.html</a><br>
[4] <a href=3D"https://developers.redhat.com/rhel8/getrhel8/" rel=3D"norefe=
rrer" target=3D"_blank">https://developers.redhat.com/rhel8/getrhel8/</a><b=
r>
[5]<br>
<a href=3D"https://access.redhat.com/support/cases/#/case/new?intcmp=3Dhp%7=
Ca%7Ca3%7Ccase" rel=3D"noreferrer" target=3D"_blank">https://access.redhat.=
com/support/cases/#/case/new?intcmp=3Dhp%7Ca%7Ca3%7Ccase</a><br>
<br>
<br>
</blockquote></div>
--00000000000021223005884f64c6--