Re: Inode 2885482 (000000008e814f64): i_reserved_data_blocks (2) not cleared!

[Theodore Ts'o]

On Fri, Oct 15, 2021 at 02:06:52AM +0800, Gao Xiang wrote:
> On Thu, Oct 14, 2021 at 12:54:14PM +0000, Rantala, Tommi T. (Nokia - FI/Espoo) wrote:
> > Hi,
> > 
> > I'm seeing these i_reserved_data_blocks not cleared! messages when using ext4
> > with nodelalloc, message added in:
> > 
> >   commit 6fed83957f21eff11c8496e9f24253b03d2bc1dc
> >   Author: Jeffle Xu <jefflexu@xxxxxxxxxxxxxxxxx>
> >   Date:   Mon Aug 23 14:13:58 2021 +0800
> > 
> >       ext4: fix reserved space counter leakage
> > 
> > I can quickly reproduce in 5.15.0-rc5-00041-g348949d9a444 by doing some
> > filesystem I/O while toggling delalloc:
> > 
> > 
> > while true; do mount -o remount,nodelalloc /; sleep 1; mount -o remount,delalloc /; sleep 1; done &
> > git clone linux xxx; rm -rf xxx
> 
> If I understand correctly, switching such option implies
> sync inodes to write back exist delayed allocation blocks.

Well, no.  What it implies is that all writes after the remount into
an unallocated portion of the file will be allocated at the time when
the page is dirtied, instead of when the page is written back.  It's
possible for some pages to be written using delayed allocation, and
some other pages in the legacy "allocate on page dirty" mechanism.
This can happen when the file system is remounted; it can also happen
when the file system starts getting close to 100% full.  See the
comment in ext4_nonda_switch:

	/*
	 * switch to non delalloc mode if we are running low
	 * on free block. The free block accounting via percpu
	 * counters can get slightly wrong with percpu_counter_batch getting
	 * accumulated on each CPU without updating global counters
	 * Delalloc need an accurate free block accounting. So switch
	 * to non delalloc when we are near to error range.
	 */

Cheers,

					- Ted