[OpenAFS] freezes acessing /afs/.git
Wed, 13 Aug 2014 10:35:00 -0400 (EDT)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
I think someone mentioned an exclude list as a possible solution to this
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...
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 OpenAFSfirstname.lastname@example.org