linux-ext4 - Re: Inode 2885482 (000000008e814f64): i_reserved_data

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YWinzKvlbx0XlJKJ@mit.edu>
Date:   Thu, 14 Oct 2021 17:57:32 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Gao Xiang <hsiangkao@...ux.alibaba.com>
Cc:     "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@...ia.com>,
        "jefflexu@...ux.alibaba.com" <jefflexu@...ux.alibaba.com>,
        "enwlinux@...il.com" <enwlinux@...il.com>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Inode 2885482 (000000008e814f64): i_reserved_data_blocks (2) not
 cleared!

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@...ux.alibaba.com>
> >   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