On Fri, May 03, 2019 at 03:25:25PM -0400, Nico Kadel-Garcia wrote:
(I put all your comments into one block)
None of the problems you've described sound familiar to me at all,
however I've only been using AFS since 1999. Unsurprisingly, there
have been improvements in the code, and the in-kernel AFS client is a
completely different client than the Transarc client from your era and
also different from a modern OpenAFS client.
The AFS kernel modules of the IBM era are known to have suffered from the following
limitations and implementation flaws:
1. distributed lock hierarchy violations resulting in distributed dead locks
2. /afs was backed by the configured cell's "root.afs" volume. If there
were connectivity issues or the fileservers failed to serve the volume, then there could
be extended timeouts
3. most afs servers were configured to restart every Sunday morning and required the
equivalent of "fsck" on every afs volume before restarting which would result in
volumes becoming unavailable for an extended period of time.
4. all location server address information was stored in local configuration files. If
IP address changes were not reflected in local configuration updates, cache managers would
experience timeouts or loss of access.
These are just a few of the many issues that have been addressed over the decades. kafs
is a 100% clean room implementation specifically designed for and integrated with the
Linux kernel. kafs does not mount "root.afs" volumes instead it follows the
"dynamic root" model whereby /afs/ directory entries are evaluated on demand as
cell names using a combination of DNS and local configuration files. OpenAFS and
AuriStorFS servers are rarely configured for weekly restarts and when they do restart the
startup time is in fractions of a second instead of hours. kafs attempts to be as
"zero config" as possible. I'm not sure if there is anything more than
specifying the name of the top-level mount point.
In any case, these implementation defects from the 90s should have no bearing on the
packaging of kafs-client for Fedora. The AF_RXRPC and AFS kernel features have been
shipping in Fedora kernels distributed with F28, F29, and F30. The kafs-client package
is the final piece required to permit end users to choose the native Linux implementation
over third-party, out-of-tree, GPL2 license incompatible implementations.
Sincerely,
Jeffrey Altman