[OpenAFS] Firefox & OpenAFS home directory (was: Request for testing: NATs
Sat, 21 Dec 2013 11:06:59 +0200 (EET)
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.
> 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@example.com>
>> >> 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
>> >> today. However, when I straced firefox, there are indications that a
>> >> missing /etc/ld.so.nohwcap file and installed "preload" package may
>> >> 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
>> > 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
>> > OpenAFSfirstname.lastname@example.org
>> > 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/
> OpenAFS-info mailing list