> 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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
