On Wed, Apr 22, 2020 at 02:15:28PM -0600, Andreas Dilger wrote: > On Apr 22, 2020, at 10:00 AM, Jan Kara <jack@xxxxxxx> wrote: > > On Tue 14-04-20 00:02:07, Josh Triplett wrote: > >> Is there a fundamental reason that ext4 *can't* or *shouldn't* support > >> inline data with 128-byte inodes? > > > > Well, where would we put it on disk? ext4 on-disk inode fills 128-bytes > > with 'osd2' union... > > There are 60 bytes in the "i_block" field that can be used by inline_data. Exactly. But the Linux ext4 implementation doesn't accept inline data unless the system.data xattr exists, even if the file's data fits in 60 bytes (in which case system.data must exist and have 0 length). > > Or do you mean we should put inline data in an external xattr block? Definitely not, no. That seems much more complex to deal with. I'm only talking about the case of files or directories <= 60 bytes fitting in the inode with 128-byte inodes. Effectively, this would mean accepting inodes with the inline data flag set, whether they have the system.data xattr or not. > Maybe there is a bigger win for small directories avoiding 4KB leaf blocks? > > That said, I'd be happy to see some numbers to show this is a win, and > I'm definitely not _against_ allowing this to work if there is a use for it. Some statistics, for ext4 with 4k blocks and 128-byte inodes, if 60-byte inline data worked with 128-byte inodes: A filesystem containing the source code of the Linux kernel would save about 1508 disk blocks, or around 6032k. A filesystem containing only my /etc directory would save about 650 blocks, or 2600k, a substantial fraction of the entire directory (which takes up 9004k total without inline data). - Josh Triplett
