Hello everyone,

In series 2, I have fixed the formatting with clang-format of the lzfse
library and fixed the comments to use linux kernel styles. I also
removed my Copyright from files where it was not appropriate. 
Additionally, I removed the encode.c files as they were unused and 
not compiled into the final module They should be easy enough to add 
back if needed. I also rebased on Linus's tree, just in case. 
Nothing broke! ;)

I am holding off on adding Ernesto's Co-developed-by and Signed-off-by
tags until I get a better grasp of where this module is headed. I hope
to here back from Christian and the LSFMMBPF folks sometime in the next
few weeks.

I understand the jury is still out on supporting both reading and
writing. As it stands, I have configured the code to support
reading/writing on mount, but upstream auto-rw is configurable via a
CONFIG option. Some people have expressed that they want the module
upstreamed even if only read is supported. I will stay tuned and make
changes as needed.

Additionally, I realize that staging/ may not be the correct location
for the driver. However, I am basing my upstream process off of the
erofs process. They started in staging. I understand that the correct
tree and dir will be discussed as next weeks LSFMMBPF summit, 
so I will wait on their feedback before making any moves.

I am curious to hear everyone's thoughts on this and to start getting
the ball rolling for the code-review process. Please feel free to
include/CC anyone who may be interested in this driver/the review
process. I have included a few people, but have certainly missed others.

Ernesto, the original author, encouraged me to submit any code
improvements upstream instead of submitting here. I am upstreaming my 
code improvements to his tree, but I will continue the effort here in
caes upstream fs folks are interested. In any case, my goal here is to
create discussion around the project and make the code better while I am
at it.

Some people on Asahi channels have mentioned that this driver could be
helpful for implementing certain features like the fingerprint reader and
simplify the boot process some. This feedback encourages me to continue
with this effort. Asahi folks, keep at it, y'all are awesome.

[0]: https://lore.kernel.org/lkml/20250307165054.GA9774@eaf/

Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
---
Changes in v2:
- remove Ethan copyright in files
- cleanup/format lzfse code and comments
- fix a few checkpatch problems
- Link to v1: https://lore.kernel.org/r/20250314-apfs-v1-0-ddfaa6836b5c@ethancedwards.com

---
Ethan Carter Edwards (8):
      staging: apfs: init lzfse compression library for APFS
      staging: apfs: init unicode.{c,h}
      staging: apfs: init apfs_raw.h to handle on-disk structures
      staging: apfs: init libzbitmap.{c,h} for decompression
      staging: apfs: init APFS
      staging: apfs: init build support for APFS
      staging: apfs: init TODO and README.rst
      MAINTAINERS: apfs: add entry and relevant information

 MAINTAINERS                                      |    6 +
 drivers/staging/Kconfig                          |    2 +
 drivers/staging/apfs/Kconfig                     |   13 +
 drivers/staging/apfs/Makefile                    |   10 +
 drivers/staging/apfs/README.rst                  |   87 +
 drivers/staging/apfs/TODO                        |    7 +
 drivers/staging/apfs/apfs.h                      | 1192 ++++++++
 drivers/staging/apfs/apfs_raw.h                  | 1566 +++++++++++
 drivers/staging/apfs/btree.c                     | 1174 ++++++++
 drivers/staging/apfs/compress.c                  |  441 +++
 drivers/staging/apfs/dir.c                       | 1439 ++++++++++
 drivers/staging/apfs/extents.c                   | 2370 ++++++++++++++++
 drivers/staging/apfs/file.c                      |  163 ++
 drivers/staging/apfs/inode.c                     | 2234 +++++++++++++++
 drivers/staging/apfs/key.c                       |  337 +++
 drivers/staging/apfs/libzbitmap.c                |  448 +++
 drivers/staging/apfs/libzbitmap.h                |   32 +
 drivers/staging/apfs/lzfse/lzfse.h               |   86 +
 drivers/staging/apfs/lzfse/lzfse_decode.c        |   66 +
 drivers/staging/apfs/lzfse/lzfse_decode_base.c   |  725 +++++
 drivers/staging/apfs/lzfse/lzfse_encode_tables.h |  224 ++
 drivers/staging/apfs/lzfse/lzfse_fse.c           |  214 ++
 drivers/staging/apfs/lzfse/lzfse_fse.h           |  632 +++++
 drivers/staging/apfs/lzfse/lzfse_internal.h      |  599 ++++
 drivers/staging/apfs/lzfse/lzfse_tunables.h      |   50 +
 drivers/staging/apfs/lzfse/lzvn_decode_base.c    |  721 +++++
 drivers/staging/apfs/lzfse/lzvn_decode_base.h    |   53 +
 drivers/staging/apfs/lzfse/lzvn_encode_base.h    |  105 +
 drivers/staging/apfs/message.c                   |   29 +
 drivers/staging/apfs/namei.c                     |  132 +
 drivers/staging/apfs/node.c                      | 2069 ++++++++++++++
 drivers/staging/apfs/object.c                    |  315 +++
 drivers/staging/apfs/snapshot.c                  |  683 +++++
 drivers/staging/apfs/spaceman.c                  | 1433 ++++++++++
 drivers/staging/apfs/super.c                     | 2098 ++++++++++++++
 drivers/staging/apfs/symlink.c                   |   77 +
 drivers/staging/apfs/transaction.c               |  959 +++++++
 drivers/staging/apfs/unicode.c                   | 3156 ++++++++++++++++++++++
 drivers/staging/apfs/unicode.h                   |   27 +
 drivers/staging/apfs/xattr.c                     |  911 +++++++
 drivers/staging/apfs/xfield.c                    |  171 ++
 41 files changed, 27056 insertions(+)
---
base-commit: a7f2e10ecd8f18b83951b0bab47ddaf48f93bf47
change-id: 20250210-apfs-9d4478785f80

Best regards,
-- 
Ethan Carter Edwards <ethan@ethancedwards.com>

I don't think this filesystem should be merged.  The real upstream
is out of tree.

regards,
dan carpenter

On 2025/3/20 08:13, Ethan Carter Edwards wrote:
> Hello everyone,
> 
> In series 2, I have fixed the formatting with clang-format of the lzfse
> library and fixed the comments to use linux kernel styles. I also
> removed my Copyright from files where it was not appropriate.
> Additionally, I removed the encode.c files as they were unused and
> not compiled into the final module They should be easy enough to add
> back if needed. I also rebased on Linus's tree, just in case.
> Nothing broke! ;)
> 
> I am holding off on adding Ernesto's Co-developed-by and Signed-off-by
> tags until I get a better grasp of where this module is headed. I hope
> to here back from Christian and the LSFMMBPF folks sometime in the next
> few weeks.
> 
> I understand the jury is still out on supporting both reading and
> writing. As it stands, I have configured the code to support
> reading/writing on mount, but upstream auto-rw is configurable via a
> CONFIG option. Some people have expressed that they want the module
> upstreamed even if only read is supported. I will stay tuned and make
> changes as needed.
> 
> Additionally, I realize that staging/ may not be the correct location
> for the driver. However, I am basing my upstream process off of the
> erofs process. They started in staging. I understand that the correct
> tree and dir will be discussed as next weeks LSFMMBPF summit,
> so I will wait on their feedback before making any moves.

I don't know why erofs is related to your case here:

  - erofs is not a project based on reserve engineering from the
    beginning; it was a real productizied project initially designed
    for Android and got wider adoption for various use cases now;

  - It was a story 6 years ago (I've been actively working on this
    project more than 7 years and it sacrificed my extra free time and
    some other possibility), more recent fses instead directly land
    into "fs/" and it seems the preferred way.  But, nevertheless,
    there is also some fs like ntfs3 directly into "fs/" and got some
    dispute;

  - I have no idea if you have enough professional experience to
    resolve apfs-specific issues properly and in time.  I think it's
    a basic requirement for a kernel subsystem upstream maintainer now
    that you introduced this;

  - And you'd better to keep relatively active during the entire Linux
    kernel lifetime even that is not related to your ongoing work
    rather than dump and leave.

Thanks,
Gao Xiang

+cc Slava and Adrian

I'm interested in bringing apfs upstream to the community, and perhaps slava and adrian too.

Thx,
Yangtao

Hi Yangtao,

On Mon, 2025-05-12 at 04:11 -0600, Yangtao Li wrote:
> +cc Slava and Adrian
> 
> I'm interested in bringing apfs upstream to the community, and perhaps slava and adrian too.

I don't have much experience with APFS yet other than using it on my
Macs and maintaining the apfsprogs package in openSUSE, but adding
APFS support to the kernel would certainly be a welcome improvement.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Hi Yangtao,

On Mon, May 12, 2025 at 04:11:22AM -0600, Yangtao Li wrote:
> I'm interested in bringing apfs upstream to the community, and perhaps
> slava and adrian too.

Do you have any particular use case in mind here? I don't mind putting in
the work to get the driver upstream, but I don't want to be fighting people
to convince them that it's needed. I'm not even sure about it myself.

Ernesto

Hi Ernesto，

On 5/13/25 7:40 AM, Ernesto A. Fernández wrote:
> Hi Yangtao,
> 
> On Mon, May 12, 2025 at 04:11:22AM -0600, Yangtao Li wrote:
>> I'm interested in bringing apfs upstream to the community, and perhaps
>> slava and adrian too.
> 
> Do you have any particular use case in mind here? I don't mind putting in
> the work to get the driver upstream, but I don't want to be fighting people
> to convince them that it's needed. I'm not even sure about it myself.

Now that some current use cases have already been provided, I'm curious 
about what the biggest obstacles are at present. APFS in the kernel 
should have better performance than a FUSE implementation. Are there any 
TODO items moving forward in this direction, such as IOMAP support and 
other similar things? I can't guarantee that I have a lot of time to 
invest heavily in this at the moment, but there should be others who are 
interested.

Thx,
Yangtao

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

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@suse.com>
SUSE Labs, CR

Hi,
just one nitpick:

On Wed, May 21, 2025 at 12:14:53PM +0200, Jan Kara wrote:
> 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.

For the record, my fsck [1] is far more thorough than the official one, I
don't take data corruption lightly. It's only for testing though, it doesn't
actually fix anything. And of course it could have mistakes since the
specification is incomplete and buggy.

[1] https://github.com/linux-apfs/apfsprogs

Ernesto A. Fernández 於 2025/5/13 清晨7:40 寫道:
> Hi Yangtao,
>
> On Mon, May 12, 2025 at 04:11:22AM -0600, Yangtao Li wrote:
>> I'm interested in bringing apfs upstream to the community, and perhaps
>> slava and adrian too.
> Do you have any particular use case in mind here? I don't mind putting in
> the work to get the driver upstream, but I don't want to be fighting people
> to convince them that it's needed. I'm not even sure about it myself.

These are the use cases I can think of:


1. When running Linux on Apple Silicon Mac, accessing the xART APFS volume is required for enabling some SEP
functionalities.

2. When running Linux on iPhone, iPad, iPod touch, Apple TV (currently there are Apple A7-A11 SoC support in
upstream), resizing the main APFS volume is not feasible especially on A11 due to shenanigans with the encrypted
data volume. So the safe ish way to store a file system on the disk becomes a using linux-apfs-rw on a (possibly
fixed size) volume that only has one file and that file is used as a loopback device.

(do note that the main storage do not currently work upstream and I only have storage working on A11 downstream)

3. Obviously, accessing Mac files from Linux too, not sure how big of a use case that is but apparently it is
big enough for hfsplus to continue receive patches here and there.
>
> Ernesto
>
Nick Chan

Hi Nick,

On Tue, May 13, 2025 at 12:13:23PM +0800, Nick Chan wrote:
> 2. When running Linux on iPhone, iPad, iPod touch, Apple TV (currently there are Apple A7-A11 SoC support in
> upstream), resizing the main APFS volume is not feasible especially on A11 due to shenanigans with the encrypted
> data volume. So the safe ish way to store a file system on the disk becomes a using linux-apfs-rw on a (possibly
> fixed size) volume that only has one file and that file is used as a loopback device.

That's very interesting. Fragmentation will be brutal after a while though.
Unless you are patching away the copy-on-write somehow?

> 3. Obviously, accessing Mac files from Linux too, not sure how big of a use case that is but apparently it is
> big enough for hfsplus to continue receive patches here and there.

True, but the hfsplus driver is already merged and people may be relying on
it. Still, there was some push to get rid of it recently. I don't expect
much support for picking up a whole new driver.

Ernesto

Ernesto A. Fernández 於 2025/5/15 凌晨4:19 寫道:
> Hi Nick,
>
> On Tue, May 13, 2025 at 12:13:23PM +0800, Nick Chan wrote:
>> 2. When running Linux on iPhone, iPad, iPod touch, Apple TV (currently there are Apple A7-A11 SoC support in
>> upstream), resizing the main APFS volume is not feasible especially on A11 due to shenanigans with the encrypted
>> data volume. So the safe ish way to store a file system on the disk becomes a using linux-apfs-rw on a (possibly
>> fixed size) volume that only has one file and that file is used as a loopback device.
> That's very interesting. Fragmentation will be brutal after a while though.
> Unless you are patching away the copy-on-write somehow?'
On a fixed size (preallocated size == max size) volume with only a single non-sparse file on it,
copy-on-write should not happen. I believe the xART volume is also the same case with only
one non-sparse file.


[...]
> Ernesto
Nick Chan

On Thu, May 15, 2025, at 07:08, Nick Chan wrote:
> Ernesto A. Fernández 於 2025/5/15 凌晨4:19 寫道:
>> Hi Nick,
>>
>> On Tue, May 13, 2025 at 12:13:23PM +0800, Nick Chan wrote:
>>> 2. When running Linux on iPhone, iPad, iPod touch, Apple TV (currently there are Apple A7-A11 SoC support in
>>> upstream), resizing the main APFS volume is not feasible especially on A11 due to shenanigans with the encrypted
>>> data volume. So the safe ish way to store a file system on the disk becomes a using linux-apfs-rw on a (possibly
>>> fixed size) volume that only has one file and that file is used as a loopback device.
>> That's very interesting. Fragmentation will be brutal after a while though.
>> Unless you are patching away the copy-on-write somehow?'
> On a fixed size (preallocated size == max size) volume with only a 
> single non-sparse file on it,
> copy-on-write should not happen. I believe the xART volume is also the 
> same case with only
> one non-sparse file.

Yeah, the gigalocker file on the xART volume (which is the only file we care about
for eventual Secure Enclave support on M1+ macs) is stored contiguously without
copy-on-write on the disk.



Sven

On Tue 13-05-25 12:13:23, Nick Chan wrote:
> 
> Ernesto A. Fernández 於 2025/5/13 清晨7:40 寫道:
> > Hi Yangtao,
> >
> > On Mon, May 12, 2025 at 04:11:22AM -0600, Yangtao Li wrote:
> >> I'm interested in bringing apfs upstream to the community, and perhaps
> >> slava and adrian too.
> > Do you have any particular use case in mind here? I don't mind putting in
> > the work to get the driver upstream, but I don't want to be fighting people
> > to convince them that it's needed. I'm not even sure about it myself.
> 
> These are the use cases I can think of:
> 
> 
> 1. When running Linux on Apple Silicon Mac, accessing the xART APFS
> volume is required for enabling some SEP functionalities.
> 
> 2. When running Linux on iPhone, iPad, iPod touch, Apple TV (currently
> there are Apple A7-A11 SoC support in upstream), resizing the main APFS
> volume is not feasible especially on A11 due to shenanigans with the
> encrypted data volume. So the safe ish way to store a file system on the
> disk becomes a using linux-apfs-rw on a (possibly fixed size) volume that
> only has one file and that file is used as a loopback device.
> 
> (do note that the main storage do not currently work upstream and I only have storage working on A11 downstream)
> 
> 3. Obviously, accessing Mac files from Linux too, not sure how big of a use case that is but apparently it is
> big enough for hfsplus to continue receive patches here and there.

I can see that accessing APFS filesystem is useful at times. But the
question is: why do we need it in the kernel? Why isn't a FUSE driver
enough? Because for relatively niche usecase like this that is a much more
acceptable (and easier to maintain) choice.

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