lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 23 Apr 2020 13:56:34 +0200 From: Jan Kara <jack@...e.cz> To: Josh Triplett <josh@...htriplett.org> Cc: Andreas Dilger <adilger@...ger.ca>, Jan Kara <jack@...e.cz>, Ext4 Developers List <linux-ext4@...r.kernel.org> Subject: Re: Inline data with 128-byte inodes? 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@...e.cz> 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@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists