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:   Mon, 2 Mar 2020 15:04:17 +0800
From:   Murphy Zhou <jencce.kernel@gmail.com>
To:     "Theodore Y. Ts'o" <tytso@mit.edu>
Cc:     Murphy Zhou <jencce.kernel@gmail.com>, linux-ext4@vger.kernel.org
Subject: Re: ENOSPC inline_data fsck failure
Message-ID: <20200302070417.ldaoyxenqkixny43@xzhoux.usersys.redhat.com>
References: <20200228105234.n5wt5x2vi3ftxuyh@xzhoux.usersys.redhat.com>
 <20200229181711.GD7378@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200229181711.GD7378@mit.edu>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

On Sat, Feb 29, 2020 at 01:17:11PM -0500, Theodore Y. Ts'o wrote:
> 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

Thanks Ted for the confirmation!

-- 
Murphy