linux-ext4 - Re: Inline data with 128-byte inodes?

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <331CEA49-83E0-462C-A70D-479F17A4FAB2@dilger.ca>
Date:   Wed, 22 Apr 2020 14:15:28 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Jan Kara <jack@...e.cz>, Josh Triplett <josh@...htriplett.org>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: Inline data with 128-byte inodes?

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.

> Or do you mean we should put inline data in an external xattr block?

Using an 4KB xattr block would IMHO be worse than just using a regular
file block for such files, if they don't fit into the 60 i_block bytes.
That makes the data handling more complex (data copies each time in/out
of the xattr) and has performance impact (all writes essentially data
journal because they go via the setxattr code path.

The only time it _might_ be useful is if there are other xattrs that are
shared in the external block with inline_data.  However, at that point
I think you are better off to just create larger inodes to hold the
xattrs to avoid the seeking needed to load the external block...

Given the prevalence of xattrs today (SELinux springs to mind), I'd be
surprised whether this combination shows any improvement in real life,
but I don't have an _objection_ to allowing this combination (e.g. for
ultra-compact /etc or boot filesystem images.

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.

Cheers, Andreas

>> As far as I can tell, the kernel ext4 implementation only allows inline
>> data with 256-byte or larger inodes, because it requires the system.data
>> xattr to exist, even if the actual data requires 60 bytes or less. (The
>> implementation in debugfs, on the other hand, handles inline data in
>> 128-byte inodes just fine. And it seems like it'd be fairly
>> straightforward to change the kernel implementation to support it as
>> well.)
>> 
>> For filesystems that don't need to store xattrs in general, and can live
>> with the other limitations of 128-byte inodes, using a 128-byte inode
>> can save substantial space compared to a 256-byte inode (many megabytes
>> worth of inode tables, versus 4k for each file between 61-160 bytes),
>> and many small files or small directories would still fit in 60 bytes.
> --
> Jan Kara <jack@...e.com>
> SUSE Labs, CR

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)