On Fri, May 03, 2019 at 03:25:25PM -0400, Nico Kadel-Garcia wrote: > On Fri, May 3, 2019 at 5:22 AM David Howells <dhowells@xxxxxxxxxx> wrote: > > Well, there's 35 years of history, expectation, experience, documentation and > > scripting for a start that expect the global AFS namespace to be mounted on > > /afs on a UNIX box (Windows is different). > > Including the fact that, since its invention, it has *always* demanded > a reboot of the client using it to clear the status of "/afs" in the > root filesystem from screwing up basic system opertations that check > anytingn in /. It's never worked well. > > And it destabilizes the client by locking up any queries of "/", > mandating a reboot at least once a week. I first encountered that > issue in the 1980's, and again lat MIT in the 1990's. Since those > systems all got forced reboots anyway, on at least a weekly basis even > if someone was logged into the workstations, it was And over time, it > was deemed pretty pointless with autofs enabled NFS mounting thgouth > "/net/$SERVERNAME/". As best I can tell, the "/afs/" automounting > generated lockups of the "/" directory was never fixed. Do you have > any experience that contradicts this weekly reboot requirement? > > See above. It hung up kernel "stat" operations on the "/" directory, > with increasing delays over the course of roughly a week until it > could be cleared only by a reboot. It's a not an unheard of problem > with confused mountpoints of any type that are mounted directly under > "/", and it's one of the reasons the FSH delegates subdirectories. (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. There are legacy isssues with runaway updatedb or find processes getting lost in /afs, but you'd get that in any sufficiently large complex NFS shares with hard mounts. And as with autofs, the dynamic AFS mounting with the kAFS module would not show any subdirectories to be traversed by an automated process. > According to the Linux kernel notes about KAFS: > > This filesystem provides a fairly simple secure AFS filesystem driver. It is > under development and does not yet provide the full feature set. The > documentation is at > https://www.kernel.org/doc/Documentation/filesystems/afs.txt, and > says: > > The features it does support include: > > (*) Security (currently only AFS kaserver and KerberosIV tickets). > (*) File reading and writing. > (*) Automounting. > (*) Local caching (via fscache). > It does not yet support the following AFS features: > (*) pioctl() system call. > > Does this sound ready for general Fedora use? It looks like the documentation describing the features was last updated in 2009. There's been significant effort in the past year to improve the in-kernel AFS code. I'll ask if maybe we can get that file updated with more recent features. I know that I've been using it exclusively with krb5 tickets for months for read and write. I also know that the pioctl() system call support will never happen, and is being replaced with other methods. -- Jonathan Billings <billings@xxxxxxxxxx> _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
