[OpenAFS] Re: Request for testing: NATs and 1.6.6pre*
Sat, 21 Dec 2013 09:59:33 +0200
On Sat, Dec 21, 2013 at 09:33:45AM +0200, Jukka Tuominen wrote:
> Thank you Atro,
> That is very promising, I will look into it. I remember tweaking ff preferences more network friendly earlier, but this particular one I can't recall.
If you read the whole discussion, the storage.nfs_filesystem flag is
actually not that helpful. It causes the profile to become uneditable,
> I'd be happy to fix the ff issue, but I still think there is something more generic also. Propably it is not NAT related, but I may try it anyhow to be on the safe side.
I haven't followed the discussion that closely, but the Firefox case
is quite separate from AFS (specifically) and more related to using
any form of non-local filesystem as your home directory, and to how
SQLite interacts poorly with database files on network filesystems.
See http://www.sqlite.org/lockingv3.html, specifically "6.0 How to
Corrupt Your Database Files"
> br, jukka
> Sent from my iPhone
> > On 21.12.2013, at 0.28, Atro Tossavainen <firstname.lastname@example.org> wrote:
> >> On Sat, Dec 21, 2013 at 12:17:05AM +0200, Jukka Tuominen wrote:
> >> These hangs can last 10+ seconds over WAN, but not quite a minute at least
> >> today. However, when I straced firefox, there are indications that a
> >> missing /etc/ld.so.nohwcap file and installed "preload" package may be
> >> causing at least part of the problem. Maybe the system is trying speed up
> >> things by loading files to memory, but the loaded files are not local. I
> >> need to study this a bit further.
> > My experience (going back a few years, at this point) is that Firefox
> > is painfully slow when your home directory is on AFS, even when the
> > client and servers are connected through a gigabit LAN.
> > I think it has to do with the sqlite databases that Firefox is using.
> > If you google "firefox slow network home directory", you can find a few
> > Mozilla bugs where the context is that the home directories are on AFP
> > (Macs with Mac networking).
> > Nathan Froyd had this to offer in one such discussion:
> > (This is in https://bugzilla.mozilla.org/show_bug.cgi?id=918612)
> > "My guess is that xFetch and xUnfetch don't work properly across remote shares. I think sqlite should be fixed, but we'd need a short-term solution. Maybe there's an SQLite VFS for Unix that DTRT with remote drives...does setting the boolean pref storage.nfs_filesystem to true help out at all?"
> > To which Steven Michaud replied:
> > "> does setting the boolean pref storage.nfs_filesystem to true help out at all?
> > Yes! It cleared the problem right up.
> > You probably want to try this, Marty. Note that the setting doesn't already exist -- you need to create it in about:config."
> > Marco Bonardo comments:
> > "I think there are various issues here.
> > First bug 719952 shows that we have a long story of problems on remote shares, basically most remote FS are bogus and Sqlite makes its best, but won't be able to work flawlessy cause the FS lies to it."
> > I'm getting a headache already.
> > Cheers, Atro
> > --
> > Atro Tossavainen, Chairman of the Board
> > Infinite Mho Oy, Helsinki, Finland
> > tel. +358-44-5000 600, http://www.infinitemho.fi/
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFSemail@example.com
> > https://lists.openafs.org/mailman/listinfo/openafs-info
> OpenAFS-info mailing list
Atro Tossavainen, Chairman of the Board
Infinite Mho Oy, Helsinki, Finland
tel. +358-44-5000 600, http://www.infinitemho.fi/