On 11/10/22 22:25, Alexandre Merlin wrote:
Hello, TL;DR: Because of our use of a script-based map that dynamically creates exports server-side based on user's rights, we are experiencing a regression since commit 2f562f63a (autofs-5.1.6 - use a valid timeout in lookup_prune_one_cache()). Creating an option for a configurable positive_timeout, as mentioned in the commit comment, would be an efficient solution for us. We are working for the Grid'5000 scientific testbed (see https://www.grid5000.fr/w/Grid5000:Home). Our users can reserve nodes to make their experiments, and from these nodes, they can access to different NFS shares if they are granted access to use them. We use autofs to mount these filesystems on the fly, using a map based on a script which checks that the user is granted, and which asks for the creation of the appropriate export file on the corresponding NFS server. When the reservation is done, we signal the node's automount daemon using the USR1 and HUP signals in order to forget what was automounted by the user (as compute nodes may be shared by different users, we want to ensure that the previously mounted resource is no more in the running configuration). For this to work, our granting access script must be called each time a user request to access a mounted point. But since the commit [2f562f63a] introducing the positive timeout, when a user tries to access a mounted point, the cache is used if a another user used the same mounted point within the positive timeout timeframe (120s). So we need a way to disable the cache to be sure that our granting script is called. It can be done for the NEGATIVE_TIMEOUT but not yet for the POSITIVE_TIMEOUT. Since it is mentioned in the commit message that "The valid timeout probably should become configurable at some point too", we wonder if it would be possible to include it in a future release. You will find attached a patch introducing this new option.
Well, yes, that will be fine. The patch looks mostly fine too, I'll possibly change some of the wording but it should be otherwise unchanged. Are you ok with having your email address as the patch author since the patch will be uploaded to kernel.org when it's committed (publicly available) or should I set myself as the author (not my preferred choice)? Anyway, I need to find time to make a new release so it shouldn't too long before it's available. If you need me to commit the patch earlier than I otherwise would (such as your distro maintainer has upstream first policy on package changes) then say so and I'll commit it. Ian
