On Fri, May 3, 2019 at 5:22 AM David Howells <dhowells@xxxxxxxxxx> wrote: > I really don't want to have to tell ordinary users that "you can't use this > unless you first go and write some systemd scripting". If you're willing to take on the work to activate afs dependent structures and components, it becomes your responsibility to integrate it well. > > \And violating a much more important, namely the File System Hiearchy. > > If you can find a good reason to violate that, publish your reasoning. > > 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. > For the in-kernel AFS client to "work out of the box", it must mount the > dynamic root on /afs. That is what people who use AFS generally expect. 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? I'm not insisting it's not been fixed, but it was a big pain at the time. > > By the way, I've dealt with /afs style automounting before, and it was > > a nightmare to clean up after when it inevitably croaked precisely due > > to the root filesystem location of "/afs". > > "a nightmare to clean up"? "inevitably croaked"? "precisely due to the root > filesystem location"? Please elaborate. 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. > "umount /afs" or "systemctl stop afs.mount" will unmount the kafs (the > in-kernel afs filesystem) dynroot and all its automounts. Note that kafs > works differently to, say, OpenAFS. OpenAFS has a single superblock that is > the entire AFS namespace and every volume, every vnode you access appears in > there. kafs, however, creates a superblock for each volume and uses the > d_automount dentry operation to operate AFS mount points. > > David 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? _______________________________________________ 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
