Nico Kadel-Garcia <nkadel@xxxxxxxxx> 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. By "you" are you referring to me personally, or anyone wanting to use the kafs client? If you're referring to someone wanting to just use the kafs client, why should they need to do anything other than install kafs-client? Say they're a student at a university that has an already-existing AFS infrastructure. They should just be able to install kafs-client, then they should immediately be able access the infrastructure with no required local configuration, provided the infrastructure includes DNS SRV or AFSDB records telling kafs where to find the cell's Volume Location servers and appropriate kerberos servers. > > > \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. Perhaps kafs is different? You can unmount things in /afs directly. You can evict all unbusy mounted cells by: for i in /afs/*; do umount $i; done But to some extent what you're describing is not the fault of AFS, no matter the client driver. Whatever is trawling the rootfs can observe the crossing into a separate filesystem. I should make statx() set attributes to tell you that (a) it's a general automounter, (b) it's a network filesystem and (c) the dirs are automount points - then the trawlers can work out for themselves to leave this alone. > > 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? kafs and AF_RXRPC have been written from scratch, sharing zero code with OpenAFS, Transarc or whatever you were using in the 1980s and 1990s. > 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. What's mounted on /afs by kafs is a pseudo-volume that's not backed by the network. Think of it as kafs's own automounter. Doing a stat on it is a trivial operation. Directories can be made in it by lookup of cell names (or by preloading). > > "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? That's a bit out of date. See: https://www.infradead.org/~dhowells/kafs/ https://www.infradead.org/~dhowells/kafs/todo.html The pioctl thing is the most vexing bit. Linus point-blank refuses to let the pioctl interface into the code, so I'm having to build in workarounds: https://www.infradead.org/~dhowells/kafs/user_interface.html David _______________________________________________ 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
