Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <331CEA49-83E0-462C-A70D-479F17A4FAB2@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_41251E72-9075-4224-B207-F3AB9394B244";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Inline data with 128-byte inodes?
Date:   Wed, 22 Apr 2020 14:15:28 -0600
In-Reply-To: <20200422160045.GC20756@quack2.suse.cz>
Cc:     Ext4 Developers List <linux-ext4@vger.kernel.org>
To:     Jan Kara <jack@suse.cz>, Josh Triplett <josh@joshtriplett.org>
References: <20200414070207.GA170659@localhost>
 <20200422160045.GC20756@quack2.suse.cz>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk


--Apple-Mail=_41251E72-9075-4224-B207-F3AB9394B244
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On Apr 22, 2020, at 10:00 AM, Jan Kara <jack@suse.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@suse.com>
> SUSE Labs, CR


--Apple-Mail=_41251E72-9075-4224-B207-F3AB9394B244
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAl6gpeAACgkQcqXauRfM
H+Cxiw//UtPXgAlqlfQ4fWDBHFocITU/qPt1qh0JFMCWjwi57MJuBJMzTixcicts
0zOYtjJw4HrQq6EkPeKwik45sS2KgMuHbXoqUF7R9hlaIfFcmZY3CIxyEwsLr5VG
vxr3Fkq4SvT4qXcR95T2D1g1sEvT2N7C7mtaaepnuEUrJzllfqQdtZlBrGRSSAnQ
fdqM4Qy4HrEVpScoTDA9VK6BgzEK6TA50b2BYSOupjbew5FiKmo7hYq+RnJlK3fY
ODFg4VVD5mMNF0+uFvdlXZH4lnUN+pQwWUw2fK/4KnGdmCnSjS2tjQivC689gDns
gIx2Hurj3g6r5CjiZPSfBCCDSWZCaIds5O26qpxAj5YIxIJr53xTI+TL2BsFP5qx
AaLBXyp4hNWOQKs/Aw21FAWdHtMIdj6iAQjERURjSmMTDxZ1RxJR5D2aHbuNtTKU
EIHKGiHD4QELdifsdz5cRqpfgTJ4FsLRMbL9rYPEv6tkAL6Iavl9yKIpj5oNdmxb
x2TsYO3w4rUEkIsVZRCrF9LF2KkGb1BTpWSp9o2mcUOWVO7sop719tEdsB2OhXfl
KigmaMSrPdTNeNASbsjHbZ775pol+vLEbfuHQHQc1DAGP1UZU+idJVUDpICM2/tg
g6WwGleU7OkD8iZrO8vHK6dqltfs5Y4fFp1imGzfvfh1WUCMWy0=
=+/UI
-----END PGP SIGNATURE-----

--Apple-Mail=_41251E72-9075-4224-B207-F3AB9394B244--