OK, that is unfortunate. Additionally, ff profile sharing between two or more simultaneous sessions didn't work the last time I tried it. Both are very old issues, so they feel like design decisions against network use.
With some reservations, I try to find time to see whether there are any recent improvements. Apparently, either of my previously mentioned tweaks "# touch /etc/ld.so.nohwcap and # apt-get purge preload") got rid of the 10+ second freezes. Still far from optimal. br, jukka > 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 > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
