On Sun, Feb 9, 2020 at 10:18 PM Zygo Blaxell <ce3g8jdj@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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
