linux-kernel - Re: Subject: [RFC PATCH v2 0/8] staging: apfs: init APFS filesystem support

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: <20250520185939.GA7885@eaf>
Date: Tue, 20 May 2025 15:59:39 -0300
From: Ernesto A. Fernández <ernesto.mnd.fernandez@...il.com>
To: Yangtao Li <frank.li@...o.com>
Cc: ethan@...ancedwards.com, asahi@...ts.linux.dev, brauner@...nel.org,
	dan.carpenter@...aro.org, ernesto@...ellium.com,
	gargaditya08@...e.com, gregkh@...uxfoundation.org, jack@...e.cz,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-staging@...ts.linux.dev, sven@...npeter.dev, tytso@....edu,
	viro@...iv.linux.org.uk, willy@...radead.org, slava@...eyko.com,
	glaubitz@...sik.fu-berlin.de
Subject: Re: Subject: [RFC PATCH v2 0/8] staging: apfs: init APFS filesystem
 support

Hi again,

On Tue, May 20, 2025 at 01:08:54PM +0800, Yangtao Li wrote:
> Now that some current use cases have already been provided

Some interesting use cases have been mentioned, yes, but I doubt they are
common enough to convince upstream to pick up a whole new filesystem. I was
also more curious about your own personal interest in the driver, because
you are going to get some very hostile feedback if you try to get it merged.
You won't get anywhere without strong conviction in the matter.

> I'm curious about what the biggest obstacles are at present.

I don't think there are any big technical problems, the driver is fairly
usable at this point and it's been a while since xfstests found any
corruption bugs. But it's still a reverse engineered filesystem, and there
will always be risks. There's also the issue of the buffer heads, but Ted
Ts'o has said before that it doesn't matter much.

The real obstacle is that I have no idea how to convince people that this is
a good idea, and nobody else is going to do it for me. There were no replies
to Jan Kara's obvious and fairly friendly objection; it's going to get much
worse than that if you try to push this through.

Personally, I just don't mind maintaining the driver out of tree.

> APFS in the kernel should have better performance than a FUSE
> implementation.

Sure, but how much better? You could try running benchmarks against the two
existing (read-only) fuse implementations. And if the driver is indeed much
faster, does that matter to you for any particular reason? Keep in mind that
you need to convince Jan Kara, not me.

Anyway, it's nice when people get interested in your projects and I do
appreciate that. But I just don't see it happening.

Ernesto