linux-ext4 - Re: I have one idea to improve ext4 filesystem efficientcy

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] [day] [month] [year] [list]

Message-ID: <20250724125324.GB80823@mit.edu>
Date: Thu, 24 Jul 2025 08:53:24 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Sergio Abreu <dosergio@...il.com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: I have one idea to improve ext4 filesystem efficientcy

On Thu, Jul 24, 2025 at 08:56:49AM -0300, Sergio Abreu wrote:
> 
> I have studied it deeply and now I want to contribute with an idea that
> could be used for next versions from ext4 and ahead
> 
> It's a simple thing that is fully compatible with current Ext4 version and
> will improve space efficiency.
> 
> I don't really want to write code, just transfer my vision to an already
> envolved and competent programmer that is working on ext4 development.
> 
> Now I just wanted to share a tech insight that would improve ext4 efficiency
> even more.

Why don't you just send the idea to the list, instead of just sayting
that you would like to contribute an idea?  

I will note that in general, ideas are generally not the bottleneck.
The bottleneck is software engineering time / bandwidth.  Either it
needs to come with a volunteer who is passionate enough to pursue the
implementation effort, or it needs to align with some company's
business goals, and so will allow their software engineer to dedicate
their work time towards the project.  Because file system engineering
is so demanding, and reiability is critical, most few features tend to
fall into that second category.

This is especially true for space efficiency, because storage per
terabyte has never been cheaper.  For example, adding support for
compression is an obvious way of improving space efficiency.  However,
the estimated cost per gigabyte in mid-2025 is roughly a penny (US
Dollars) using hard drives.  The cost per gigabyte stored on NVMe
flash is about 8 cents USD.  When you factor into that the cost of a
software engineer, whether in Brazil, US, China, India, etc., it's
hard for a company to justify such an investment.  And this does't
take into account that there are other performance tradeoffs involved
in using compression.  As the saying goes, there's no such thing as a
free lunch.

Cheers,

					- Ted