linux-ext4 - Re: [PATCH 1/3] ext4: do not allow external inodes for inline data

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: <C32B2E07-C045-40FB-A397-377AEB09BB11@dilger.ca>
Date:   Thu, 24 May 2018 14:29:25 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Ext4 Developers List <linux-ext4@...r.kernel.org>,
        wen.xu@...ech.edu, jannh@...gle.com
Subject: Re: [PATCH 1/3] ext4: do not allow external inodes for inline data

On May 24, 2018, at 2:20 PM, Theodore Y. Ts'o <tytso@....edu> wrote:
> On Thu, May 24, 2018 at 10:51:21AM -0600, Andreas Dilger wrote:
>> On May 23, 2018, at 9:37 AM, Theodore Ts'o <tytso@....edu> wrote:
>>> 
>>> The inline data feature was implemented before we added support for
>>> external inodes for xattrs.  It makes no sense to support that
>>> combination, but the problem is that there are a number of extended
>>> attribute checks that are skipped if e_value_inum is non-zero.
>>> 
>>> Unfortunately, the inline data code is completely e_value_inum
>>> unaware, and attempts to interpret the xattr fields as if it were an
>>> inline xattr --- at which point, Hilarty Ensues.
>> 
>> I guess the separate question is whether this should also check for
>> "inline data" in an external xattr block and disallow that also?
>> On the one hand, "inline data" in an external block doesn't make
>> sense - why not just store the data in a block directly?
>> 
>> On the other hand, this might be useful at some point in the future
>> if we have large bigalloc chunks that makes using a whole chunk for
>> a small file inefficient and we could pack the data from multiple
>> small files into a single bigalloc chunk as inline data xattrs (maybeh
>> using the inode number as xattr name to keep the xattrs unique)?
> 
> This would require fragment support and I really doubt we would ever
> go there.

I don't think we would need fragments, just a shared xattr block (chunk)
that stores a bunch of "system.<ino>" xattrs, one for each file, similar
to how inline_data has a "system.data" xattr.  This would be better than
fragments, which are typically fixed at 1/N of the blocksize.  The xattr
size can be pretty arbitrary, and would be more like tail packing than
fragments.

This would be useful for storing small files on bigalloc filesystems,
which is an area that I think bigalloc is lacking today.

Cheers, Andreas






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