On 12/11/2012 4:54 PM, Jago Pearce wrote:
> I have seen this kind of bug in so many forms for years, decades.
>
> Where a GUI is dependent on a file or network request and will freeze
> with no feedback as to what is happening.
On the flip side you look at other protocols such as SMB which have a
I have seen this kind of bug in so many forms for years, decades.
Where a GUI is dependent on a file or network request and will freeze
with no feedback as to what is happening.
Really a program should be able to have a new process or *something*
to make the file or network actions without haltin
On Tue, Dec 11, 2012 at 4:38 PM, Simon Wilkinson
wrote:
> On 11 Dec 2012, at 21:29, Brandon Allbery wrote:
> > This is what SRV records are for, yes. Ideally, the CellServDB on
> clients is for legacy use with old cells
>
> Sadly, there are loads of situations where the client CellServDB is vital
On 11 Dec 2012, at 21:29, Brandon Allbery wrote:
>
> This is what SRV records are for, yes. Ideally, the CellServDB on clients is
> for legacy use with old cells
Sadly, there are loads of situations where the client CellServDB is vital.
There are far too many SOHO broadband routers that come
Brandon Allbery writes:
> This is what SRV records are for, yes. Ideally, the CellServDB on
> clients is for legacy use with old cells that don't have SRV records in
> place (and to some extent is probably part of "don't make IBM unhappy").
> The server CellServDB is a different issue, I think,
On Tue, Dec 11, 2012 at 4:16 PM, wrote:
> I am by no means an administrator, rather a UX designer building a concept
> design as easy as possible for the end users. So, I take it, it is
> possible to build an afs client without static pointers to afs servers. I
> hope this applies to the home cel
Hi Brandon and others,
I am by no means an administrator, rather a UX designer building a concept
design as easy as possible for the end users. So, I take it, it is
possible to build an afs client without static pointers to afs servers. I
hope this applies to the home cell as well, since the user
[returning back to the list with the Wireshark results]
Excellent work Ken, thanks!
Just a few clarifications about the recording:
The system was running 1.4. during the test (with -afsdb and -dynroot).
It's a virtual environment and I can somewhat easily test either one.
I only clicked once o
There are a long list of items that can result in poor performance.
Here is a short list that is most likely incomplete:
1. VLDB addresses in CellServDB are out of date and there
in fact are no servers at those addresses
2. VLDB addresses in CellServDB are correct but the servers
have been
On 12/10/2012 6:16 PM, Ken Dreyer wrote:
> On Mon, Dec 10, 2012 at 4:08 PM, Derrick Brashear wrote:
>> There's an open "thing" in gerrit which we should complete and merge
>> to fix this.
>
> Cool, do you have a reference?
http://gerrit.openafs.org/#change,8011
signature.asc
Description:
On Mon, Dec 10, 2012 at 4:08 PM, Derrick Brashear wrote:
>
> Actually, cmdebug output (and looking at the afsdb locks) will also
> tell, and is much more reliable as an
> indicator.
Fair enough; I just don't have the expertise to read that :)
>> I just tested this with Gnome on Fedora 19 and I c
On Mon, Dec 10, 2012 at 5:33 PM, Ken Dreyer wrote:
> On Mon, Dec 10, 2012 at 3:12 PM, wrote:
>>
>> What do you mean by publishing DNS SRV records? The server has a FQDN but
>> do you mean something else?
>
> If you can get a Wireshark trace of DNS activity while Nautilus is
> frozen, that will h
Guess what -dynroot-sparse does.
On Mon, Dec 10, 2012 at 4:24 PM, Mattias Pantzare wrote:
> It helps if you have an empty CellServDB. That way you won't have a bunch of
> cells in /afs and you can still go to cells that have correct DNS records
> when you need to.
>
>
>
> On Mon, Dec 10, 2012 at
On Mon, Dec 10, 2012 at 3:12 PM, wrote:
>
> What do you mean by publishing DNS SRV records? The server has a FQDN but
> do you mean something else?
If you can get a Wireshark trace of DNS activity while Nautilus is
frozen, that will help us understand if Nautilus is causing AFS to
stall out when
On Mon, Dec 10, 2012 at 5:12 PM, wrote:
> What do you mean by publishing DNS SRV records? The server has a FQDN but
> do you mean something else?
>
Modern AFS autodiscovers the servers for a cell via DNS, much like other
modern services. See
http://tools.ietf.org/html/draft-allbery-afs-srv-rec
What do you mean by publishing DNS SRV records? The server has a FQDN but
do you mean something else?
Possibly a related issue. Our ISP rearranged IP addresses, and eventhough
it wasn't an issue for the server end, the client is a read-only image.
This time the IP number had to be changed manuall
For your home cell I assume you are using DNS AFSDB records. 1.6 looks for DNS
SRV records first, then fails over to AFSDB if they are not found. Publish DNS
SRV records for your cell.
Jeffrey Altman
On Dec 10, 2012, at 4:45 PM, jukka.tuomi...@finndesign.fi wrote:
>
> Thanks Jeffrey, that
Thanks Jeffrey, that explains things nicely. Eventhough the dns-lookups
work, I suspect it is far from optimal. If the lookup takes a fair amount
of time on top of nautilus fetching the afs content itself, it can very
well be enough to cause the timeout. Once you can cache the location and
content
It helps if you have an empty CellServDB. That way you won't have a bunch
of cells in /afs and you can still go to cells that have correct DNS
records when you need to.
On Mon, Dec 10, 2012 at 10:10 PM, Troy Benjegerdes wrote:
> This seems to be a common cause of pain for people using AFS,
> a
This seems to be a common cause of pain for people using AFS,
and I think its a user-interface experience that drives people
away.
You install AFS, and then all of a sudden you go do something
and your user-interface just hangs. You have not idea what
triggered it, you just associate 'crappy non-
-fakestat provides no benefits if the application is going to read the contents
of the volume root directory referenced by a mount point. -fakestat works by
generating fake stat info for the mount point target instead of reading the
actual data belonging to the target which might require a volu
On Dec 10, 2012, at 19:22 , jukka.tuomi...@finndesign.fi wrote:
> Hmmm... Strange things happened. After several hang-ups, being more
> patient they turned into time-outs, until... even nautilus could get
> through! First I thought that initiating nautilus from the command line -
> as part of str
Hmmm... Strange things happened. After several hang-ups, being more
patient they turned into time-outs, until... even nautilus could get
through! First I thought that initiating nautilus from the command line -
as part of strace command - did something, but then I could browse (in
vry slow mot
Yes, I received similar output. Thanks Michael!
br, jukka
> On Mon, 10 Dec 2012 00:37:38 +0200
> wrote:
>
>>
>> By "own-path" I mean local cell as opposed to foreign one.
>>
>> I believe -dynroot is on, but how could I verify this?
>
> You can verify -dynroot is enabled on a running cache mana
On Mon, 10 Dec 2012 00:37:38 +0200
wrote:
>
> By "own-path" I mean local cell as opposed to foreign one.
>
> I believe -dynroot is on, but how could I verify this?
You can verify -dynroot is enabled on a running cache manager with cmdebug.
$ cmdebug -long | grep dynroot
Lock dynroot st
On Sun, Dec 9, 2012 at 3:37 PM, wrote:
>
> By "own-path" I mean local cell as opposed to foreign one.
Oh, this may not be the same issue then. On my computer I see the GUI
freezes happening for my local cell.
You can try running nautilus through strace or gdb to see what
specifically is hanging
Thanks Harald,
I restored my normal settings and now...
$ fs lq /afs/
...returns immediately with...
fs:'/afs/': connection timed out
...leaving all the data columns empty. So, it seems the dynroot is indeed on.
br, jukka
>
>> I believe -dynroot is on, but how could I verify this?
>
> $
> I believe -dynroot is on, but how could I verify this?
$ fs lq /afs/
Volume NameQuota Used %Used Partition
root.afs.readonly 5000 561% 5%
This is a real volume name -> no dynroot here.
If you have dynroot, it can not give you a
I read the documentation for dynroot, and it's not something to sacrifice
really. Anyhow, I reconfigured openafs temporarily to remove the dynroot
just to test if it changes the situation, but no.
So the local cell works fine with gui and foreign cells only from the
command line. Strange...
br,
By "own-path" I mean local cell as opposed to foreign one.
I believe -dynroot is on, but how could I verify this?
If I'm to turn it off, are there any sacrifices expected?
br, jukka
> Can you give more information about what you mean by your own afs-path?
>
> Are you using -dynroot when sta
Can you give more information about what you mean by your own afs-path?
Are you using -dynroot when starting the afsd process? On Xfce I've
noticed that the dynroot feature can conflict with GVFS's trash
implementation, causing the Thunar GUI to freeze, and I imagine
Nautilus would have a similar
Hi,
graphical file managers (nautilus & gnome-commander at least) seem to get
stuck when listing directories other than own afs-path. Fakestat is on and
it works fine with own afs-path (I suppose due to fakestat), but trying to
change it to fakestat-all didn't seem to help. Command line listing w
32 matches
Mail list logo
