linux-kernel - Re: Different writeback timing since v5.14

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 2 Mar 2022 10:24:15 +0100
From:   Jan Kara <jack@...e.cz>
To:     Richard Weinberger <richard@....at>
Cc:     Jan Kara <jack@...e.cz>, wuchi zero <wuchi.zero@...il.com>,
        Rafał Miłecki <zajec5@...il.com>,
        tj <tj@...nel.org>, mszeredi <mszeredi@...hat.com>,
        sedat dilek <sedat.dilek@...il.com>, axboe <axboe@...com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        torvalds <torvalds@...ux-foundation.org>,
        linux-mm <linux-mm@...ck.org>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Different writeback timing since v5.14

On Tue 01-03-22 16:05:54, Richard Weinberger wrote:
> Jan,
> 
> ----- Ursprüngliche Mail -----
> > Von: "Jan Kara" <jack@...e.cz>
> >> Is this expected?
> >> Just want to make sure that the said commit didn't uncover an UBIFS issue.
> > 
> > Yes, I think it is expected. Likely the background threshold for UBIFS bdi
> > is very small (probably UBIFS is not used much for writeback compared to
> > other filesystems). Previously, we just used wb_stat() which returned 0
> > (PCP counter inexact value) and so background writeback didn't trigger. Now
> > we use wb_stat_sum() when threshold is small, get exact value of dirty
> > pages and decide to start background writeback.
> 
> Thanks for the prompt reply!
> 
> > The only thing is, whether it is really expected that the threshold for
> > UBIFS bdi is so small. You can check the values in
> > /sys/kernel/debug/bdi/<bdi>/stats.
> 
> BdiDirtyThresh is indeed 0.
> 
> BdiWriteback:                0 kB
> BdiReclaimable:              0 kB
> BdiDirtyThresh:              0 kB
> DirtyThresh:            772620 kB
> BackgroundThresh:       385836 kB
> BdiDirtied:                  0 kB
> BdiWritten:                  0 kB
> BdiWriteBandwidth:      102400 kBps
> b_dirty:                     0
> b_io:                        0
> b_more_io:                   0
> b_dirty_time:                0
> bdi_list:                    1
> state:                       1

Yes, so this looks expected given the BDI wasn't active yet at all...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR