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: <n7kkoptktdvldadvymcfmnaw3yqbk6bfmzpxvgdkpsvvpc3p7i@ilqcgz7wur7i>
Date: Wed, 21 May 2025 12:14:53 +0200
From: Jan Kara <jack@...e.cz>
To: 
	Ernesto A. Fernández <ernesto.mnd.fernandez@...il.com>
Cc: Yangtao Li <frank.li@...o.com>, 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!

On Tue 20-05-25 15:59:39, Ernesto A. Fernández wrote:
> 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.

Correct, this kind of matches my feelings from this discussion so far. Sure
APFS support in the kernel would be more convenient for some users. But so
far I didn't hear a reason why FUSE driver wouldn't cover 99% of the
usecases (since I know close to nothing about Apple ecosystem, maybe I've
missed some so please correct me in that case).

Perhaps to explain the reasons of a pushback a bit: Once the filesystem
driver is merged, it's very difficult to get rid of it as users may depend
on it. Each filesystem driver adds certain maintenance burden - most
notably for changes in VFS and other generic infrastructure that need to
take into account what each and every filesystem is doing. We already carry
quite a few filesystem drivers used by very few people and since few people
are interested it them it's difficult to find people to get these drivers
converted to new mount API, iomap infrastructure, new page cache APIs etc.
which forces us to keep carring the old interfaces. This gets particularly
painful for filesystems where we don't have full specification so usually
the mkfs and fsck tooling is not as comprehensive which makes testing
changes harder. So the bar (in terms of usecases) to get the new filesystem
driver merged is relatively high.

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

Using FUSE to access the filesystem certainly has it's overhead (although
there is work in progress to heavily reduce that for data-intensive
operations such as streaming IO). But I doubt your the usecase for APFS is
to use it as a backend for a file server or a database. We have other
filesystems in Linux for that. All the usecases I've heard are about being
able to access you Mac files from Linux. And FUSE driver should have
acceptable performance for that from my experience.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR