I have faced similar issues at times. If you like everything about the
current behavior of AFS aside from the impact it can have on git you might
attack it from the git side. Maybe there is a way to stop git from
recursing all the way to /afs/ ? Similar solutions have worked for me with
things other than git. You probably don’t want git to check that directory
anyway, even if you can make it happen much faster.

Ed

On Fri, Aug 26, 2022 at 22:14 Jeffrey E Altman <jalt...@auristor.com> wrote:

> On 8/26/2022 5:13 PM, Ingo van Lil (ing...@gmx.de) wrote:
>
> Hello OpenAFS experts,
>
> is there any way to run an AFS client with both the -dynroot and -afsdb
> options, but still limit the /afs mount point to known cells
> (specifically: only my home cell)?
>
> There is no explicit support for this behavior in OpenAFS but you might be
> able to approximate it by
>
>    - enabling -dynroot
>    - disabling -afsdb
>    - removing the OpenAFS distributed CellServDB file
>    - creating a CellServDB file contain only one line for the cell and no
>    servers
>    >my.cell # My personal cell
>
> A cell entry with no servers is an implicit request to lookup the servers
> via DNS.
> I do not remember if this works with -afsdb disabled but it might.
>
>
> Longer explanation of my problem:
>
> When I run "git status" somewhere inside the AFS hierarchy it freezes
> for a minute or two. git tries to access the directory /afs/.git, and I
> see that afsd sends multiple DNS requests to the loopback address
> 127.0.0.53. Not sure why it does that, it seems to be somehow related to
> systemd-resolved in Fedora Linux.
>
> Running without -dynroot solves the issue, but according to the manual
> it will keep my machine from booting in case my home cell can't be
> contacted. Not very attractive.
>
> Running without -afsdb solves the issue. That's what I do now, but it
> requires to manually specify the servers for my home cell in CellServDB.
> Ideally I'd like to get that info from DNS.
>
> Thanks in advance for any advice you can give!
>
> Regards,
> Ingo
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
> --
Edward A. Rude
Systems Administrator - Unix Systems
Division of Information Technology

Reply via email to