Recursive mounts with kAFS, but not with OpenAFS

[Jeffrey Altman]

> On May 3, 2024, at 6:20 AM, Jan Henrik Sylvester <jan.henrik.sylvester at uni-hamburg.de> wrote:
> 
> Hello,
> 
Hello Jan,

> I hope this is the correct forum to ask and I do not have to be subscribed to the list.

This is the correct mailing list to discuss net/rxrpc, fs/afs, kafs-client and related functionality.
> 
> kAFS and OpenAFS behave differently if there are recursive mounts. Should one of the behaviors be considered a bug?

Kafs behaves differently from OpenAFS in many respects.   One significant way that kafs differs is that each AFS or AuriStorFS volume is a distinct device.   Another significant difference is that kafs does not have a path based ioctl interface.
> 
> For each users' home directory, we (uni-hamburg.de) create a mount point of its respective backup volume AFSBAK directly below the home directory itself. That way ~/AFSBAK is a snapshot from the backup of last night for ~ and the users can find lost files themselves.

This is fairly common.
> 
> That was never a problem with OpenAFS, because ~/AFSBAK/AFSBAK is invalid (No such device). Now I am evaluating kAFS for our clients (long term plan, now triggered by the fact that there is no OpenAFS for Ubuntu 24.04, yet)

Ubuntu 24.04 is less than a week old and although AuriStorFS clients are available for it one of the significant benefits of kafs on distributions that support it is that it’s built in.  There is never a wait for its availability or a need to synchronize an out-of-tree kernel module with the running kernel.

> and a simple execution of find on a home directory had a machine hang by the oom-killer killing vital system processes, because kAFS can go more than a 1000 levels recursively into ~/AFSBAK/AFSBAK/AFSBAK...

Markus Suvanto reported the same problem on Feb 20th.   At the time Marc Dionne developed a patch to prevent the evaluation of a mount point to a volume name with the “.backup” extension from a volume of type AFSVL_BACKVOL.   Testing of the patch wasn’t complete so it did not get submitted.   Hopefully Marc can submit it next week.   Once merged by Linus it can be back ported to the actively maintained stable kernels.
> 
> The volume user is mounted to /afs/math.uni-hamburg.de/users/area/user and user.backup is mounted to /afs/math.uni-hamburg.de/users/area/user/AFSBAK. Should /afs/math.uni-hamburg.de/users/area/user/AFSBAK/AFSBAK automatically be a mount point?

It's a mount point but should not be traversed.

> Thanks,
> Jan Henrik

Jeffrey Altman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3929 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20240504/1893fbcb/attachment.p7s>