Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Nov 2018 02:48:21 +0000
From:      B J <va6bmj@gmail.com>
To:        Polytropon <freebsd@edvax.de>
Cc:        freebsd-questions <freebsd-questions@freebsd.org>
Subject:   Re: Kernel Panics With Firefox 63.x
Message-ID:  <CAP7QzkOVcUR6wycThj4dVf6GAh_DVz%2B%2B7JJgukwYKQcNDD=33w@mail.gmail.com>
In-Reply-To: <20181113224915.9429e289.freebsd@edvax.de>
References:  <CAP7QzkN_6sGAh66Am2oTfDmazWUD6Gxq2d5ss-kNewjcRoc5RA@mail.gmail.com> <20181113182954.1d7060bd.freebsd@edvax.de> <CAP7QzkN66pSTOmw0HAPsDAzRgxRtLXRgoqFZnAvNoXW1eLq5uQ@mail.gmail.com> <20181113201830.f0eec001.freebsd@edvax.de> <CAP7QzkO8=A-DVa7GxEXv0gpJL4MnDirz6DVfzF%2B6GdAF9h7aag@mail.gmail.com> <20181113205020.afc446d9.freebsd@edvax.de> <CAP7QzkOXYUZfaNxzUvH_XOmn7eE4ueT6E83H3TX%2BER9ETKy_fw@mail.gmail.com> <20181113224915.9429e289.freebsd@edvax.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On 11/13/18, Polytropon <freebsd@edvax.de> wrote:

<snip>

>> I halted the building process and did as you suggested earlier.  There
>> were indeed a number of inconsistencies and corrupted files when I ran
>> fsck in single-user mode.
>
> Excellent!
>
> Always make sure the file system consistency is present
> _before_ the system boots; relying on background fsck
> just asks trouble. ;-)
>
> Technical sidenote: The background fsck can only handle
> a subset of errors. Common errors, sure, but sometimes
> there is something it cannot correct or repair, and you
> boot into an inconsistent system state, but without any
> warning. A foreground fsck makes sure that _if_ such a
> problem is recognized, you will be interactively prompted,
> so you can decide what to do. In very few cases you do
> _not_ want fsck to do anything, as it might make data
> recovery more problematic; for example, you first decide
> to "mount -o ro /something", retrieve data, then run
> fsck and maybe end up with zero length files (whose
> content you have already recovered), and then you "re-fill"
> those files; or you need to use fsdb to help fsck with
> a problem it cannot work around.
>
> However, for typical use, a foreground fsck will be the
> right thing to do. You gain safety by paying with downtime.
> You usually don't pay with data loss. :-)

I've used fsck when working with external hard drives, but it never
dawned on me to use it for the main one.

<snip>

> Firefox today uses a quite complex structure of files to
> store settings. Combine this with a file system inconsistency,
> and you can easily end up with files that get rewritten or
> reset, but are still damaged at the next program start.
> In case the same inodes were used, the file would always
> be somehow damaged, and even if a process of unlink() and
> open() / fopen() to create it would allocate a different
> inode, it's still possible that the problem was within the
> parent inode - and only a proper fsck would have been able
> to fix this problem.

<snip>

I remember that Firefox used to be shown as a single process when
running top.  In the last year or so, it was changed and now it uses
several of them.  If I want to kill FF, I have to do it to just about
every one of them.  How many there are seems to be related to factors
such as the number of tabs or windows I might have open.

I've been running the newly-installed FF for the past few hours and
there hasn't been any problems yet.

BMJ



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAP7QzkOVcUR6wycThj4dVf6GAh_DVz%2B%2B7JJgukwYKQcNDD=33w>