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

[Zhou, Yun]

Hi Ted, 
 

 
 

Thanks for the thoughtful suggestion.

On 7/27/26 23:03, Theodore Tso wrote:
> 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.

The "boring file" argument assumes benign workloads. Under adversarial 
conditions (which CVE assignments reflect), any race window is 
exploitable regardless of how unlikely it is under normal use.

> 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.

With 64K blocks, the internal fragmentation alone wastes on average 32K 
per file (vs. 2K with 4K blocks).  For a filesystem with n files, the 
extra tail waste is n * 30K. Meanwhile, enlarging the inode (say to 4K) 
wastes m * 3840B for *all* pre-allocated inodes (m > n), used or not.

A system configured to accept this level of space waste for performance 
is unlikely to care about saving one 64K block per small file.  And if 
small files are rare enough to tolerate 64K blocks, inline data benefits 
even fewer files.

> 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.

This is an interesting approach and could potentially work. That said, 
new mechanisms often introduce new race conditions. Do the minor gains 
truly justify the added complexity? No major distribution enables 
inline_data by default. The feature has been available for 14 years and 
remains opt-in, suggesting the benefit has never been compelling enough 
for general use.

It's not worth introducing new complexity for a feature that has no 
actual users and keeps introducing bugs. However, I am open to 
investigating this further in the hope of finding a good balance.

BR,
Yun