Re: [RFC PATCH 0/9] ext4: phase out inline data write paths for regular files

["Theodore Tso" <tytso@mit.edu>]

On Mon, Jul 27, 2026 at 06:54:32PM -0500, Yun Zhou wrote:
> 
> The inline_data feature has been a persistent source of bugs in
> ext4 over the past three years...
> 
> The root cause is architectural: inline data requires special handling
> in write_begin/write_end, writepages, page_mkwrite, truncate, and
> directory operations, with complex locking interactions between
> xattr_sem, i_rwsem, i_data_sem, and page locks.
> 
> The benefit is minimal: inline data saves at most one 4K block per
> small file.  In practice, very few regular files are small enough to
> benefit from inline storage -- mostly only small directories gain from
> it.  Major distributions do not enable inline_data by default in
> mkfs.ext4.

I agree that inline_data feature has been a persistent source of bugs,
and is relatively minimal for data files.  Howvever, the regular files
that are small enough to support inline data come really boring filess
where we're not doing the really stressful things that fsx, fstress,
syzbot, etc. do to punish the file system.

I do think there will be some systems where there might be enough
small files (especially when the blocksize is 64k, and the inode size
is larger --- perhaps 4k) where it might be worthwhile to support the
"boring" inline data files, e.g., small config files, header files
etc., where the file is written once, and closed, and never modified
again.

So what if we had a mechanism where we're using delayed allocation, if
the are no open file descriptor, so races and deadlocks can be
avoided, and in that case, we can write it as an inline regular data
file.  Otherwise, we back it using a regular block.  I think this
would get us 95% of the benefits of inline data files, with much less
of the complexity cost.

What do you think of that approach?

					- Ted