From: "Ernesto A. Fernández" <ernesto.mnd.fernandez@gmail.com>
To: Yangtao Li <frank.li@vivo.com>
Cc: ethan@ethancedwards.com, asahi@lists.linux.dev,
brauner@kernel.org, dan.carpenter@linaro.org,
ernesto@corellium.com, gargaditya08@live.com,
gregkh@linuxfoundation.org, jack@suse.cz,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-staging@lists.linux.dev, sven@svenpeter.dev, tytso@mit.edu,
viro@zeniv.linux.org.uk, willy@infradead.org, slava@dubeyko.com,
glaubitz@physik.fu-berlin.de
Subject: Re: Subject: [RFC PATCH v2 0/8] staging: apfs: init APFS filesystem support
Date: Tue, 20 May 2025 15:59:39 -0300 [thread overview]
Message-ID: <20250520185939.GA7885@eaf> (raw)
In-Reply-To: <226043d9-068c-496a-a72c-f3503da2f8f7@vivo.com>
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
next prev parent reply other threads:[~2025-05-20 18:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 0:13 [RFC PATCH v2 0/8] staging: apfs: init APFS filesystem support Ethan Carter Edwards
2025-03-20 0:13 ` [PATCH RFC v2 1/8] staging: apfs: init lzfse compression library for APFS Ethan Carter Edwards
2025-03-20 3:00 ` Aditya Garg
2025-03-20 0:13 ` [PATCH RFC v2 2/8] staging: apfs: init unicode.{c,h} Ethan Carter Edwards
2025-03-20 0:13 ` [PATCH RFC v2 3/8] staging: apfs: init apfs_raw.h to handle on-disk structures Ethan Carter Edwards
2025-03-20 0:13 ` [PATCH RFC v2 4/8] staging: apfs: init libzbitmap.{c,h} for decompression Ethan Carter Edwards
2025-03-20 0:13 ` [PATCH RFC v2 5/8] staging: apfs: init APFS Ethan Carter Edwards
2025-03-20 0:13 ` [PATCH RFC v2 6/8] staging: apfs: init build support for APFS Ethan Carter Edwards
2025-03-20 0:13 ` [PATCH RFC v2 7/8] staging: apfs: init TODO and README.rst Ethan Carter Edwards
2025-03-20 0:13 ` [PATCH RFC v2 8/8] MAINTAINERS: apfs: add entry and relevant information Ethan Carter Edwards
2025-03-20 0:43 ` [RFC PATCH v2 0/8] staging: apfs: init APFS filesystem support Gao Xiang
2025-03-20 5:39 ` Dan Carpenter
2025-05-12 10:11 ` Subject: " Yangtao Li
2025-05-12 23:40 ` Ernesto A. Fernández
2025-05-13 4:13 ` Nick Chan
2025-05-13 10:43 ` Jan Kara
2025-05-13 11:41 ` Aditya Garg
2025-05-14 20:19 ` Ernesto A. Fernández
2025-05-15 5:08 ` Nick Chan
2025-05-15 16:00 ` Sven Peter
2025-05-20 5:08 ` Yangtao Li
2025-05-20 18:59 ` Ernesto A. Fernández [this message]
2025-05-21 10:14 ` Jan Kara
2025-05-21 16:27 ` Ernesto A. Fernández
2025-05-15 5:10 ` John Paul Adrian Glaubitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250520185939.GA7885@eaf \
--to=ernesto.mnd.fernandez@gmail.com \
--cc=asahi@lists.linux.dev \
--cc=brauner@kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=ernesto@corellium.com \
--cc=ethan@ethancedwards.com \
--cc=frank.li@vivo.com \
--cc=gargaditya08@live.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=slava@dubeyko.com \
--cc=sven@svenpeter.dev \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).