[OpenAFS] Firefox & OpenAFS home directory (was: Request for testing: NATs and 1.6.6pre*)

[Jukka Tuominen]

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 <openafs@atrotossavainen.fi>
>> 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
>> > OpenAFS-info@openafs.org
>> > https://lists.openafs.org/mailman/listinfo/openafs-info
>> _______________________________________________
>> OpenAFS-info mailing list
>> OpenAFS-info@openafs.org
>> 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
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>