Re: data rolled back 5 hours after crash, long fsync running times, watchdog evasion on 5.4.11

[Chris Murphy <lists@colorremedies.com>]

On Sun, Feb 9, 2020 at 10:18 PM Zygo Blaxell
<ce3g8jdj@umail.furryterror.org> wrote:
>
> On Sun, Feb 09, 2020 at 06:49:11PM -0700, Chris Murphy wrote:
> > On Sat, Feb 8, 2020 at 5:43 PM Zygo Blaxell
> > <ce3g8jdj@umail.furryterror.org> wrote:
> > >
> > > Upon reboot, the filesystem reverts to its state at the last completed
> > > transaction 4441796 at #2, which is 5 hours earlier.  Everything seems to
> > > be intact, but there is no trace of any update to the filesystem after
> > > the transaction 4441796.  The last 'fi usage' logged before the crash
> > > and the first 'fi usage' after show 40GB of data and 25GB of metadata
> > > block groups freed in between.
> >
> > Is this behavior affected by flushoncommit mount option? i.e. do you
> > see a difference using flushoncommit vs noflushoncommit? My suspicion
> > is the problem doesn't happen with noflushoncommit, but then you get
> > another consequence that maybe your use case can't tolerate?
>
> Sigh...the first three things anyone suggests when I talk about btrfs's
> ridiculous commit latency are:
>
>         1.  Have you tried sysctl vm.dirty_background_bytes?
>
>         2.  Have you tried turning off flushoncommit?
>
>         3.  Have you tried cgroupsv2 parameter xyz?
>
> as if those are not the first things I'd try, or set up a test farm
> to run random sets of parameter combinations (including discard, ssd cache
> modes, etc) to see if there was any combination of these parameters that
> made btrfs go faster, over any of the last five years.

Nope. It was a yes or no question, not a suggestion. I don't
understand the problem enough to make a suggestion.


--
Chris Murphy