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]
Date:   Wed, 22 Apr 2020 18:00:45 +0200
From:   Jan Kara <jack@...e.cz>
To:     Josh Triplett <josh@...htriplett.org>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: Inline data with 128-byte inodes?

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...

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

								Honza

> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ