
Apple File System - sirn
https://developer.apple.com/library/prerelease/content/documentation/FileManagement/Conceptual/APFS_Guide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40016999
======
killercup
> Flash / SSD Optimization

I.e., a "unique copy-on-write design"

> Space Sharing

Basically, ZFS datasets.

> Snapshots

If those can be sent: Finally Time Machine done right.

> The AFP protocol is deprecated and cannot be used to share APFS formatted
> volumes.

Interesting.

> An open source implementation is not available at this time. Apple plans to
> document and publish the APFS volume format when Apple File System is
> released in 2017.

Yay!

Limitations:
[https://developer.apple.com/library/prerelease/content/docum...](https://developer.apple.com/library/prerelease/content/documentation/FileManagement/Conceptual/APFS_Guide/UsingtheAppleFileSystem/UsingtheAppleFileSystem.html#//apple_ref/doc/uid/TP40016999-CH4-DontLinkElementID_24)

Edit:

> encryption models for each volume in a container: no encryption, single-key
> encryption, or multi-key encryption with per-file keys for file data and a
> separate key for sensitive metadata

Nice. I hope they also include checksums for each block.

Famously missing, but not the hardest thing to add considering all the
features above: Compression (which HFS+ supports!)

~~~
PinguTS
__> The AFP protocol is deprecated and cannot be used to share APFS formatted
volumes. Interesting. __

That is really interesting. I recognised with El Capitan that it already
defaults to SMB instead of AFP when you don 't give a scheme.

~~~
secalex
AFP is also a security disaster. Check out the spec for "DHX2"
[https://developer.apple.com/library/mac/documentation/Networ...](https://developer.apple.com/library/mac/documentation/Networking/Conceptual/AFP/AFPSecurity/AFPSecurity.html)

~~~
ghettoimp
Can you provide some details about what's wrong with it? (Not a security
person, no idea how to evaluate such a claim)

------
ahl
The spartan description of APFS certainly sounds like the (partial) feature
list for ZFS--the comparisons made in the comments here are on-point. ZFS
though took around 5 years to ship and, arguably, another 5-10 to get right. I
say this having shipped multiple products based on ZFS, writing code in ZFS,
and diagnosing production problems with it.

On-disk consistency ("crash protection"), snapshots, encryption, and
transactional interfaces ("atomic safe-save") will no doubt be incredibly
valuable. I don't think though though that APFS will dramatically improve upon
the time it took ZFS to mature from a first product to world-class storage.

Some commenters have opined that (despite Apple distributing ZFS for Mac OS X
at WWDC nearly a decade ago) that ZFS would never be appropriate for the
desktop, phone, or watch. True ZFS was designed for servers and storage
servers, but I don't think there's anything that makes it innately untenable
in those environments--even its default, but not essential, use of lots of
RAM.

Who knows... maybe Apple have spent the decade since killing their internal
ZFS port taking this new filesystem though the paces. Its level of
completeness though would suggest otherwise.

~~~
mioelnir
Between the ZFS-like features and the advertised "novel copy-on-write
metadata" scheme, I would not be surprised if it was partially based on
DragonFly's HAMMER/HAMMER2 filesystem.

~~~
ahl
It would be a strange kind of NIH that excluded ZFS but welcomed HAMMER...

~~~
AceJohnny2
Licensing.

------
cpr
Siracusa will finally be happy. ;-)

Sounds an awful like like ZFS (zero-cost clones, read-only snapshots) but
could it be? I would imagine they'd start from scratch to due IP issues.

Clearly this is immature technology they want to get out for
testing/evaluation before it's fully adopted even into their own products.
(See below.)

\- - - from the release notes - - -

As a developer preview of this technology, there are currently several
limitations:

Startup Disk: APFS volumes cannot currently be used as a startup disk.

Case Sensitivity: Filenames are currently case-sensitive only.

Time Machine: Time Machine backups are not currently supported.

FileVault: APFS volumes cannot currently be encrypted using FileVault.

Fusion Drive: Fusion Drives cannot currently use APFS.

~~~
DannyBee
"FileVault: APFS volumes cannot currently be encrypted using FileVault. "

This one is confusing, because this is a logical volume feature. Not sure how
or why APFS would ever care that some layer above it is encrypting stuff.

~~~
CGamesPlay
Err, per [1]

> APFS supports encryption natively. You can choose one of the following
> encryption models for each volume in a container: no encryption, single-key
> encryption, or multi-key encryption with per-file keys for file data and a
> separate key for sensitive metadata. APFS encryption uses AES-XTS or AES-
> CBC, depending on hardware. Multi-key encryption ensures the integrity of
> user data even when its physical security is compromised.

[1]
[https://developer.apple.com/library/prerelease/content/docum...](https://developer.apple.com/library/prerelease/content/documentation/FileManagement/Conceptual/APFS_Guide/GeneralCharacteristics/GeneralCharacteristics.html#//apple_ref/doc/uid/TP40016999-CH2-SW1)

~~~
DannyBee
I wonder why they went this route.

Most apple volumes are already logical volumes (check diskutil list).

FileVault itself is, right now, implemented as part of corestorage (see
diskutil cs for the encryption/decryption commands).

I assume they decided they just wanted to go the entire ZFS route and get rid
of core storage in favor of a pool model, but still ...

------
xd1936
> It is optimized for Flash/SSD storage and features strong encryption, copy-
> on-write metadata, space sharing, cloning for files and directories,
> snapshots, fast directory sizing, atomic safe-save primitives, and improved
> file system fundamentals.

\o/ Hallelujah, something modern!

~~~
quantumhobbit
I was excited to until I read the limitations section. Can't be used as the
startup disk and doesn't work with time machine.

Hopefully this with change in the next macOs release.

~~~
xd1936
Sure, this is a developer preview. Final release in 2017 will surely make this
FS the default.

~~~
lewisl9029
That's what people were hoping for with ReFS from Microsoft, which released
years ago, but that still hasn't happened yet.

~~~
whorleater
Apple is far more willing to switch to more newer technologies than Microsoft
is.

~~~
drewda
... and Microsoft is far more willing than Apple to put effort into backwards
compatibility.

~~~
niccaluim
I don't know about that. Apple switched processor architectures twice, and
both times software written for the old arch ran on the new one. And when they
replaced their entire operating system, they not only made it so you could
still program against the old API—just recompile and go—they also made it
possible to run the old OS inside the new one so you could still run apps that
hadn't yet been recompiled.

~~~
duskwuff
And before that, when Apple made the 68k -> PPC transition in the mid-90s,
they ran the whole system under a crazy, bizarre emulator that allowed for
function-level interworking - 68k code could directly call PowerPC code, and
vice versa. Early PowerPC systems were in fact running an OS that was mostly
composed of 68k code; it wasn't until 1998 or 1999 (around the release of the
iMac) that most of the Toolbox was ported to PowerPC.

------
jxy
Just saw a comment in another thread, stating Apple had slipped in improving
their Unix layer, and here comes this. New file system is not a joking matter:
Microsoft failed to deliver their new FS; Linux took years to go from ext2 to
ext3 to ext4, and btrfs is in forever testing; most of *BSD still use their
old ones; zfs took decade to become mainstream...

The information currently is very scarce on this one, but I hope they would at
least test it REALLY WELL.

~~~
izacus
Didn't Microsoft introduce ReFS with many modern FS features?

~~~
wtallis
Yes, and the list of NTFS features it dropped was just as long.

------
tdicola
I'm going to be very cynical and say that based on their track record of major
OS overhauls I am _not_ looking forward to the bugs and issues that will sneak
past their QA. I still have nightmares of all the bugs with their wifi & USB
stack changes in the last couple OSX releases. Please Apple, for your own good
don't 'move fast and break things' with the filesystem. At the very least it's
time for everyone to make sure they have a good backup system in place before
touching this thing.

~~~
MBCook
Compared to how risky and problematic HFS+ is? It may still be better.

~~~
cmurf
Exchanging problems you know for problems you don't know.

------
rleigh
While I am happy that Apple have at last committed to replacing HFS+, I'm
wondering why they didn't use ZFS rather than reinventing the wheel. It's not
like it's a particularly easy wheel to reinvent either; the amount of effort
which goes into a filesystem like ZFS is non-trivial. Why not build on top of
that?

I would have greatly appreciated being able to use ZFS with MacOS X, for
datasets, snapshots, sending them to remote pools for backup etc. It would
have made it directly interoperable with a lot of pre-existing and cross-
platform infrastructure. (I couldn't care less if it didn't scale down to the
"watch". Filesystems are not a one-size-fits-all affair.) I find it great that
I can take a set of disks from e.g. Linux, run "zpool export", pull them out,
and then shovel them into a FreeBSD system, run "zpool import" and have the
pool and datasets reassembled and automatically mounted. Perfectly transparent
interoperability and portability. While Apple like to do their own thing, this
is one place I would have definitely appreciated some down to earth pragmatism
and re-use of existing battle-tested and widely used technology.

~~~
wcummings
How does AAPL feel about the CDDL?

~~~
wstrange
Given that there are other companies shipping ZFS without Oracle's blessing, I
am curious why Apple could not do the same? (honest question)

Is it that Apple is a much bigger target? Patent issues?

~~~
zaphar
Many of those companies probably started using ZFS before Oracle acquired Sun.
After Oracle acquired Sun the risks of using ZFS skyrocketed legally and Apple
had the option of just not taking on that risk since they hadn't shipped it
yet.

Given what we know about Oracle that was probably the right call.

------
pducks32
I read the link and have a pretty good understanding about how computers and
file systems work but can someone "explain like I'm a decently intelligent
programmer" what is different about this file system? Thanks you.

~~~
cpr
They simply started from scratch with an aim to

* best support modern hardware technologies,

* start from the state of the art in file systems (like ZFS and btrfs, old as they may be), and also

* emphasize security.

~~~
astrodust
Sounds a lot like what Apple did with Swift.

------
0x0
Hopefully this will be the end of .DS_Store and the crazy unicode
normalization issue that causes mixups when rsync-roundtripping a directory
structure between ext4 and HFS! :)

~~~
rdsnsca
Doubt that. .DS_Store are created by the Finder.... not the file system.

~~~
0x0
Maybe Finder could stash that stuff elsewhere if the new file system
accomodates metadata on directories, or such.

------
ysleepy
Uh interesting thought:

With Space sharing and multiple logical volumes there will probably be a shift
to encrypting users home directories separately.

Probably even an unencrypted System Base, which is read-only and protected by
rootless anyway, so the system can boot without user interaction.

This also finally allows the most user friendly implementation of file
encryption: Encrypted Folders, supported by the OS.

Sounds cool, Id be willing to help with a rust port once the source is
available :) (case sensitive only - naturally)

~~~
derefr
The point of encrypting the base system image is mostly to make it part of the
Secure Boot chain. rootless is a policy control to stop processes from
modifying the OS from inside. An encrypted system image stops things with
hardware access (but not the unlock key) from modifying the OS from the
_outside_. You can trust any disk whose blocks you can decrypt with key X, to
have been only written to by someone with key X.

~~~
ysleepy
thanks for mansplaining rootless and encryption (/s).

Encryption is not authentication, so it does not prevent unnoticed
modification.

And secure boot only really depends on authentication and not on encryption,
so you are conflating two different concepts.

No you cant just trust the data, replay attacks over time and space are still
an issue.

~~~
derefr
I'm not the one conflating them; it's the Secure Boot people who think this is
a good idea. Full-Disk Encryption is the defined "OS" stage of the Secure Boot
chain-of-trust today, acting as an "optimization" (heh) over signing disk
blocks.

It's certainly _more secure_ (indeed, it prevents replay attacks) to just keep
a big block-hash table, update it when blocks change, and then hash that table
and sign it on fsync—but it's costly in a few ways over just trusting
unauthenticated encryption, and was even moreso five-to-eight years ago when
Secure Boot was being formulated.

These days, you see a lot of wholly-signed _read only_ OS images—the OSX
recovery partition is signed; CoreOS signs its OS images; most firmware is
signed; etc. But I don't expect the unauthenticated-encryption on most
computers' read-write rootfs will be replaced by a signed-but-unencrypted
filesystem any time soon—if just for the fact that consumers really seem to
hate the idea of separate OS and data partitions, especially when the OS
partition is "stealing space" they could be using for data. (The only thing I
can think of that might finally kill this making the default install on some
consumer-OS create a thin pool, such that an OS partition that only contains
5G of data only "steals" 5G of their "space.")

Or, y'know, authenticated encryption. Do any block-device cryptosystems
support an AEAD mode yet? LUKS maybe?

~~~
ysleepy
> "You can trust any disk whose blocks you can decrypt with key X, to have
> been only written to by someone with key X."

No you can not. That is your sentence not from Secure Boot People.

Also I assume that APFS will support encrypted and unencrypted logical FS in
the same space sharing FS instance. So the separate OS partition is just a
logical FS which is unencrypted. - Which I meant in my original post.

GELI and the AES-GCM are authenticated. Not sure if GCM has equivalent
properties to the GELI HMAC feature but probably good enough.

[https://en.wikipedia.org/wiki/Galois/Counter_Mode](https://en.wikipedia.org/wiki/Galois/Counter_Mode)

------
Philipp__
Wow! This makes me feel good, maybe Apple gets it that many of it's users use
it's devices because they present proper UNIX desktop environment. And that
environment needs to be cherished and it needs to evolve.

This is not a small thing. We had nice visual overhaul 2 years ago, now Apple
needs to pick it up on under the hood level.

------
entee
It would be really nice is there was a modern file system that "just worked"
regardless of device. I'm tired of having exFAT/FAT being the only filesystem
I can reliably use on multiple different OS-es painlessly, and even then I
can't use it for all the functions of those OS-es (No time machine). Hopefully
this will be open enough to enable that, though who knows how it will shake
out.

~~~
regularfry
[https://en.wikipedia.org/wiki/Universal_Disk_Format](https://en.wikipedia.org/wiki/Universal_Disk_Format)
? That looked hopeful last I was juggling with this sort of thing, but that
was long enough ago that WinXP support was the killer.

~~~
duskwuff
From what I understand, UDF is primarily targeted at one-time-recordable
media. (It's used in DVDs, for example.) It's unclear how well it works for
primary storage, but I suspect it's clumsy at best.

~~~
regularfry
It's only got to beat FAT. That's a pretty low bar.

~~~
setpatchaddress
One that it doesn't meet. Try to read and understand the UDF spec sometime.

------
pieterr
> You can share APFS formatted volumes using the SMB network file sharing
> protocol. The AFP protocol is deprecated and cannot be used to share APFS
> formatted volumes.

AFP deprecated too.

------
bluegreyred
I didn't see any mentions of check-summing. Please tell me this brand new
filesystem won't be susceptible to bitrot?

------
lathiat
Much like other modern filesystems such as ZFS and BTRFS it supports multiple
filesystems in a shared storage space, snapshots, copy-on-write and also has
encryption built-in as a first class feature including multiple keys and per-
file keys.

There are _many_ limitations in the developer beta so this is clearly still
very much a work in progress. Getting these file-systems right is
traditionally difficult and can take years (see ZFS, BTRFS) so it will be
interesting to see how well it does.

~~~
pmlnr
It's the transparent compression I'm using btrfs for. Only that, ZFS and NTFS
support it, so not much choices for that scenario.

------
jbergstroem
No snapshotting yet, can't boot, no migration tools for existing setups (time
machine, filevault, fusion). It'd be interesting to see whether their
permission changes introduced in 10.11 will travel further down the fs. Also,
I don't see any mention of compression like lz4. Lots of work until release in
2017!

~~~
MBCook
Is compression really that big a deal any more?

~~~
STRML
While they're still shipping machines with < 1TB SSDs (read: for a long time),
yes - why not take the relatively free space and I/O savings?

~~~
brigade
On the other hand, people (sample size: my family and friends) tend to fill up
their drives with already-compressed video and photos, which lz4 and similar
cannot really compress further.

------
rbanffy
> Case Sensitivity: Filenames are currently case-sensitive only.

Sanity, at last! (even if temporary)

~~~
zymhan
But Photoshop!

~~~
spikengineer
Adobe has to get their shit right.

------
Bytes
This is a huge feature. I have no idea why Apple didn't include this in their
keynote.

~~~
methyl
Probably too technical for a typical keynote watcher

~~~
kristofferR
Typical World Wide Developer Conference watcher? If so, that's a shame!

~~~
huxley
Opening Keynote is really for the press, it'll probably be mentioned more
prominently in the State of the Union keynotes and in its own session.

------
skrause
No checksumming?

~~~
kchoudhu
Can you implement COW filesystems without some kind of checksumming? Or have I
been in ZFS-land for too long?

~~~
Freaky
Yup. Nothing intrinsic to it that needs checksums.

    
    
        zfs set checksum=off rpool

------
watersb
If you create a ZFS filesystem on a non-macOS, you have to be careful about
Unicode mapping in order to use it safely on MacOS.

I have no idea if Unicode is an issue for Apple File System.

Emoji file names, you guys.

~~~
cynix
> Emoji file names, you guys.

But are they 3x bigger?

------
drinchev
This should've been in the keynote.

~~~
waterphone
The keynote was for consumers and the press. The 2 PM PT Platforms State of
the Union is for developers and will likely go into this more, and if not
there is a session tomorrow specifically about it.

~~~
drinchev
Still... Marketing fully-encrypted snapshot-featured filesystem with focus on
SSD / Flash, would make much more impact than having "native-tabs" for apps on
an event like that.

Anyway I'm not a specialist, just another IT guy, so maybe I'm too opinionated
to argue more.

~~~
msbarnett
The press understands "apps" and "tabs". The press doesn't understand
"filesystem snapshots".

Part of the reason Apple has historically gotten much better press from WWDC
than most tech companies do from their big developer events is that they
laser-focused their keynote on being Press-digestible and not full of
incomprehensible tech terminology that bores non-geeks to tears.

As evidenced by this thread, the people "filesystem snapshots" can be marketed
to _didn 't need it to be mentioned in the keynote to get them talking about
it_. Hence, using precious keynote time for it would have been a waste of
marketing resources.

~~~
zeckalpha
> The press understands "apps" and "tabs". The press doesn't understand
> "filesystem snapshots".

That's a limited view of the press.

------
notacoward
I'm notoriously skeptical of anything from the local-filesystem world, and I'm
no Apple fanboy, but this looks pretty cool. I look forward to hearing how
some of it works, especially what's new about their version of COW and why
end-to-end checksumming wasn't mentioned.

------
partiallogic
Paging @siracusa

~~~
oneeyedpigeon
And he said it would never happen!

~~~
noblethrasher
Actually, he said he thought that it would happen next year (2017).

~~~
cmsj
It's not happening until next year, the docs say it's coming in 2017, so I
guess a macOS 12 point release.

------
busterarm
Give me case sensitivity and file dates that go past Feb 6th 2040 please. :D

------
franciscop
I cannot see anything on my Android mobile S:

------
VeejayRampay
Website doesn't work at all on my Nexus 5x. Any other company would get
lambasted for that kind of stuff.

------
CoachRufus87
Forgive my ignorance, but what benefits would an average user experience with
this new file system?

~~~
nisa
In theory (the practical side is tricky to get right):

\- More resilience against data corruption for one due to copy on write and
likely checksumming - so in theory power failure should not harm the
filesystem and you can roll back to a last known state and only lose data for
the last few seconds if at all.

\- Snapshots, before installing updates you can snapshot the filesystem and
roll back instantly. You could also create a readonly snapshot to have
consistent backups. This should also allow seamless rollback of OS updates.
There are also clones supported e.g. multiple diverging versions of a file
tree - think something similar to git branches on a filesystem level.

\- Native encryption at the filesystem level

\- Possible better handling of metadata. Faster access to directories with
lot's of files, more files on a volume without slowdown.

\- Sparse files - you can create huge files instantly and fill them later,
guess it's important for various types of software e.g. virtual machine
images.

But as nice as these properties are in theory history showed that that in
practice a lot can go wrong.

~~~
CoachRufus87
Thank you for the explainer.

------
cjbprime
I hope they don't patent it and go after Linux implementations, as Microsoft
did with exfat.

~~~
baldfat
Well the issue was that was a closed file system owned by Microsoft and used
on Linux for Flash Drives and SD Cards.

If you sue closed technology you get burned. I didn't have a problem with
Microsoft doing what they did. We should have used an open file system for
those devices. I personally have used ext2/rfs on my drives and it is a pretty
light security system ;)

~~~
ryao
I would expect Apple's driver to be open source, so someone could just port
it. Their HFS+ driver is open source.

------
lossolo
Could anyone outline advantages and disadvantages comparing to ext4 or other
file systems?

~~~
2bitencryption
It's not HFS. That in itself is a pretty huge advantage.

~~~
amock
That's not really a useful statement. HFS+ has worked pretty well for many
years and is really well tested. This will be a completely new filesystem,
which means it will have lots of new code that can have bugs or
incompatibilities with current apps. APFS sounds like it's going to be great,
but I think not being HFS is a disadvantage rather than an advantage.

~~~
wazoox
Come on. HFS+ has been a shame for 15 years now. It's been the laughing stock
of the filesystem community for ages. They got the developer of BeFS on board
to patch the thing until it may apes a modern filesystem for a couple of days
at a time, and that's about it. It deserves to die an ugly death, strangled in
a back alley without mercy. It's about as good as LINDOS/FAT32.

God, what a relief, we're almost done with this monstrosity of HFS+. Didn't
you hear the collective sigh of anyone having to _work_ with this flea-market
antique FS?

~~~
taharvey
Technically under the covers HFS isn't anything great. But from a users point
of view apple has extended it in ways that it hasn't materss to customers.

------
lai
Oh I forgot, you can't read Apple documentation on a mobile chrome browser.

~~~
nullymcnull
Even on Chrome desktop, if you turn on Mobile emulation and switch it to
appear to be any Android device w/ phone display size, it fails in the same
way - yet switch it to 'iPhone 5' or 'iPhone 6' and the same compact layout
works fine. They're pointlessly sniffing and special-casing 'Android' user-
agents and botching it completely.

------
mailslot
Another proprietary filesystem? I was really hoping they'd adopt ZFS fully.

~~~
jasonjei
Apple says they intend to open-source the file system in the docs.

 _Open Source_ : "An open source implementation is not available at this time.
Apple plans to document and publish the APFS volume format when Apple File
System is released in 2017."

~~~
zingplex
Just like they promised to open source FaceTime and iMessages? Apple has a
history of making false promises in regards to open sourcing products.

~~~
wrigby
My understanding was that FaceTime and iMessage weren't open sourced because
of issues related to a patent troll (VirnetX IIRC). I'd be interested in
hearing from others that are more familiar with the situation.

~~~
pluckytree
Or perhaps concern with having to deal with 3rd party iMessage/Facetime
clients while at the same time trying to maintain a high level of security.
Apple doesn’t want anything to tarnish the security reputation of these
products.

------
0xCMP
What about case sensitivity?

~~~
killercup
> Current Limitations […] Case Sensitivity: Filenames are currently case-
> sensitive only.

------
PakG1
This is interesting because just yesterday I saw a discussion here on HN about
how sad people were that Apple was doing nothing to improve OSX and was
putting all the focus on iOS instead. Heh.

------
comex
I had been nervous that if and when Apple finally got around to making a new
file system, they would follow the trend and neither open source it nor
document the on-disk format. HFS+ itself has always been open by virtue of
being included in the open-sourced core xnu kernel, but Apple's CoreStorage
volume manager (the basis for FileVault and Fusion Drive) and DMG disk image
format have always lived in closed-source kernel extensions and are not
officially documented; Microsoft has acted similarly with its NTFS, ReFS, and
exFAT file systems and Storage Spaces volume manager.

The result, of course, is that nothing can access anything else's file system,
at least well. Most of the formats I mentioned have been reverse engineered to
some extent, but there are limits, especially when you're scared of corrupting
data by misinterpreting the format and therefore limit your implementation to
read access. If you want read-write access to NTFS from Linux or macOS, a
filesystem which is old enough to drink, you have to rely on either a
relatively slow FUSE implementation or some proprietary software. If you dual
boot Linux on your Mac and want access to the Mac partition, make sure to turn
off disk encryption (and hope you don't run into any evil maids) unless you
want to use a read-only FUSE tool, and I hope you don't have a Fusion Drive
because I don't think anything supports that at all (could be wrong).

To be fair, this situation cannot be blamed entirely on lack of openness. Lack
of interest matters too; as I said, HFS+ has an open source implementation,
yet Linux's hfsplus driver doesn't support journaling, a feature added in
2002. But if anyone tries to improve the situation, that implementation makes
their job a lot easier: for one thing, since filesystem support is in the BSD-
based portion of the xnu kernel, it may be possible to port the HFS
implementation to other BSDs with relative ease - like the NetBSD rump kernel,
which can run in userspace, from which FUSE support wouldn't be that hard...
Alternately, if they chose the path of enhancing the native Linux driver, at
least they could consult Apple's code to be sure they weren't missing any
obscure corners of the format that could cause their driver to corrupt data.

Anyway, what we got with Apple File System is this:

> An open source implementation is not available at this time. Apple plans to
> document and publish the APFS volume format when Apple File System is
> released in 2017.

That's pretty good! Open source plus documentation would be ideal, but
documentation is _much_ better than nothing[1], and the text of that paragraph
doesn't exactly rule out the possibility of the final release being open
source too. (I haven't installed the beta yet, but am I right in guessing that
APFS is implemented in a kext?)

While there's no guarantee, I hope that that documentation will also come with
information about the Core Storage format APFS will usually be wrapped in, so
that proper interoperability can be achieved. Rather than my fear coming to
pass of one of the last vestiges of openness in proprietary OS storage formats
disappearing, the situation may actually be improved compared to today. Maybe
in a few years I'll be able to install Ubuntu on my Mac and have full access
to the OS X partition out of the box. I can hope...

[1] whether it's better or worse than open source alone is debatable - source
can be harder to understand, but it's also never wrong, unlike
documentation...

------
cm3
Does anyone know if Dominic Giampaolo was involved with the design?

~~~
gyc
He's still at Apple so I would assume he had a major role.

~~~
cm3
I hope so, though I kinda miss the pervasive use of metadata as in BeFS. That
was before its time and such a nice concept. Coupled with saved queries, it's
unmatched to this day in mainstream, general purpose file system semantics.

------
Chyzwar
Arrogance... Instead using ZFS they build new file system from scratch (APFS)
Instead using Vulkan they build new Graphics API from scratch (Metal)

Keep this up and they will end like MS.

~~~
chucknelson
I'd be more interested in understanding why they chose to implement their own
file system instead of adopting something like ZFS.

No doubt there is reasoning in there besides the "we are an evil company"
logic - Apple developers are people too...

~~~
Chyzwar
I just do not understand rationale. File systems is hard stuff, instead taking
something that is probably best file system around they decided for long and
painful road. Note that they worked before on OpenZFS in Apple ....

------
ulfw
Shipping in 2017? So it won't even be ready for Sierra?

~~~
JonathonW
It's present as a developer preview in Sierra, but isn't the default
filesystem and can't be used as the boot drive.

Which is probably how it should be. I'd rather not lose data to a new
filesystem because Apple rushed the thing out without proper testing.

~~~
jasonjei
Seconded. File systems are hard and specs need to be finalized. Plus the
grandparent post reminds me of the old Slashdot meme: ``No wireless. Less
space than a nomad. Lame.''

------
amelius
I hope finally a filesystem that allows me to unplug a USB drive (while it is
still mounted) without potentially corrupting it.

~~~
userbinator
Any filesystem that doesn't cache writes will basically have that property,
unless you're talking about unplugging _while write operations are happening_
, in which case all bets are off.

~~~
wmf
The point of journaling/soft updates/COW/etc. is that all bets are _not_ off;
they're intended to prevent the fs from being corrupted in those sorts of
situations.

------
crest
I wonder if Apples acquisition of acunu.com is finally paying off. Is this
file system based on stratified B-trees?

------
DeepYogurt
It seems to be a b-tree based file system that isn't zfs or btrfs. Neat.

~~~
rleigh
Note that ZFS doesn't use b-trees; it uses Merkle hashes.

------
jackjeff
I don't see any mention of data integrity...

Unless you use multi-key encryption.

I find that a bit odd.

------
Black-Plaid
> Case Sensitivity: Filenames are currently case-sensitive only.

Dominic, lol.

------
sigzero
I hope this comes about unlike the ZFS fiasco.

------
geodel
Any guess if AFS is written in Swift?

~~~
ysleepy
Probably C++ like the rest of IOKit.

[https://en.wikipedia.org/wiki/I/O_Kit](https://en.wikipedia.org/wiki/I/O_Kit)
[http://opensource.apple.com/source/xnu/xnu-3248.20.55/iokit/](http://opensource.apple.com/source/xnu/xnu-3248.20.55/iokit/)

------
kevinSuttle
I wonder how APFS compares to IPFS. [https://ipfs.io/](https://ipfs.io/)

