[OpenAFS] freezes acessing /afs/.git

[Stephen Joyce]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1323285367-1407940500=:27274
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

I think someone mentioned an exclude list as a possible solution to this 
problem.

What about an include list instead (or in addition to the exclude list)?

I'm envisioning something like CellServDB, but without the actual DB info 
-- that is effectively a list of robust and/or often-used cells for which 
you're willing to look up AFSDB/SRV records?

If neither file exists, revert to the current operation.

Just an idea...

PS. Forgive me if someone mentioned that and I overlooked it. While I read 
all the messages in the thread, I'm often interrupted by work...

Cheers,
Stephen
--

On Sun, 10 Aug 2014, Markus Köberl wrote:

> On Sunday 10 August 2014 0:31:14 Troy Benjegerdes wrote:
>> This really needs some sort of testcase and regression tests.
>>
>> I keep randomly hitting this stuff and I just 'got used to' my machine
>> (or maybe just a process) become unusable for awhile. It's the kind of
>> thing that someone tries AFS, and runs into this, and then never uses
>> it again.
>
> Yes and things are changing over years so that you never know the real 
> problem. For our cell -afsdb got used since the beginning. But it got 
> much worse after the debian upgrade to wheeze. At the end all users where 
> affected. With squeeze it was only noticeable on kde. It may also 
> correlate with changes on our name server, I do not know about this as it 
> gets managed central.
>
>> Part of the problem is also applications that look for random files all
>> over the place
>>
>> I think negative caching and maybe some sort of 'cell-configured' negative
>> cache file is going to be necessary.
>
> Yes I think this will maybe solve the problem for a lot of programs. But 
> there are also things like the bash auto-completion which also get 
> affected by the timeouts where caching maybe wont work that good. But in 
> this case particular case people learn what they should not use the tab 
> key in the /afs directory.
>
> In my home network I tested a lot of settings but never got negative 
> caching with bind working probably. I observe always about 1.3s for 
> searches which should be cached. At work it was faster.
>
>
> During the weekend I disabled -afsdb at work on all hosts. I am curios 
> about the feedback... _______________________________________________ 
> OpenAFS-info mailing list OpenAFS-info@openafs.org 
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
--8323329-1323285367-1407940500=:27274--