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, or something. > 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 <[email protected]> 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 > > [email protected] > > https://lists.openafs.org/mailman/listinfo/openafs-info > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
