Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 29 Feb 2020 13:17:11 -0500
From:   "Theodore Y. Ts'o" <tytso@mit.edu>
To:     Murphy Zhou <jencce.kernel@gmail.com>
Cc:     linux-ext4@vger.kernel.org
Subject: Re: ENOSPC inline_data fsck failure
Message-ID: <20200229181711.GD7378@mit.edu>
References: <20200228105234.n5wt5x2vi3ftxuyh@xzhoux.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200228105234.n5wt5x2vi3ftxuyh@xzhoux.usersys.redhat.com>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Fri, Feb 28, 2020 at 06:52:34PM +0800, Murphy Zhou wrote:
> 
> With inline_data mkfs option, generic/083 can easily trigger
> a fsck failure like this:
> 
> The testcase is doing a simple testing: make a small(256M) fs,
> run fsstress in it,  make it out of space. Then fsck.
> 
> Not sure about is this an issue of ext4 filesystem or e2fsck
> needs more options.

This is an ext4 bug.  It's been on my radar screen to investigate one
of these days, but I've just never gotten around to it.  I'm guessing
the bug is the error handling case when an inline directory is getting
converted directory where its contents are stored in data blocks, and
the block allocation fails due to the ENOSPC.

						- Ted