On Wed 22-04-20 17:40:33, Josh Triplett wrote: > 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). I see now I understand what you meant. Thanks for explanation. > > 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). I guess few people care about a few megabytes these days... For really space sensitive applications, people don't pick ext4 as a base filesystem I'd guess (I'd expect squashfs, erofs, or ubifs if you need write access). So the benefit is relatively small, the question about the cost is - how complicated it gets to support inline data without xattrs? Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
