26 ms·

APFS in Detail

237 points by knweiss 10y ago

idorosen 10y ago
In my opinion, APFS does not seem to improve upon ZFS in several key areas (compression, sending/receiving snapshots, dedup, etc.). Apple is reimplementing many features already implemented in OpenZFS, btrfs (which itself reimplemented a lot of ZFS features), BSD HAMMER, etc. Maybe extending one of these existing filesystems to add any functionality Apple needs on top of its existing features (and, hopefully, contributing that back to the open source implementation) would cost more person-hours than implementing APFS from scratch. Maybe not. Either way, we will now have yet another filesystem to contend with, implement in non-Darwin kernels (maybe), and this adds to the overall support overhead of all operating systems that want to be compatible with Apple devices. Since the older versions of macOS (OSX) don't support APFS, only HFS+, this means Apple and others will also have to continue supporting HFS+. It just seems wasteful of everyone's time to me. Also: https://xkcd.com/927/ https://xkcd.com/927/
- lanna 10y ago
  Breaking changes sometimes are unavoidable, progress has to be made.
- matthewmcg 10y ago
  Agreed. A few years ago Apple was on the verge of using ZFS but cancelled the project due to licensing issues. See http://arstechnica.com/apple/2009/10/apple-abandons-zfs-on-mac-os-x-project-over-licensing-issues/ http://arstechnica.com/apple/2009/10/apple-abandons-zfs-on-m...
  - snarf 10y ago
    A better/more up to date article on this from the same blog as this item: http://dtrace.org/blogs/ahl/2016/06/15/apple_and_zfs/ http://dtrace.org/blogs/ahl/2016/06/15/apple_and_zfs/
- mindajar 10y ago
  Classic comic, but I don't think it applies. APFS looks intended to solve Apple's product problems really well, and it doesn't even try to be a filesystem for everyone. Apple has said from time to time that they're all about owning and controlling the key technologies that go into their products. APFS makes a lot of sense from that perspective, and this seems one of those cases where going their own way is better than importing someone else's constraints. ZFS on an Apple Watch? LOL.
  - tfar 10y ago
    I would not be surprised if one could write a ZFS implementation optimized for more constrained devices. If you already know you are going to a have flash storage you can probably ditch some of the N layers of cache you see in common ZFS implementations. Not that ZFS is a one size fits all, but the file systems specification could be implemented in more than one way.
    - mindajar 10y ago
      If you assume Apple cares about having a disk format in common with other platforms, sure, I'd agree that's probably possible. But I don't think they do; they seem to care a lot more about things like a unified codebase across their platforms, the energy-efficiency initiatives they've been pushing for a few years, owning the key tech in the products, etc. One slide in the WWDC talk deck showed a bunch of divergent Apple storage technologies across all their platforms that are being replaced by APFS. If ZFS has to fork into weird variants to run well on the phone or watch, that seems less appealing than a single codebase optimized for just the stuff Apple products do.
  - idorosen 10y ago
    Should have said s/standards/filesystems/g... :-) I was reacting to the idea of APFS for macOS, as well as having yet another filesystem to deal with on external media that interacts with multiple computers (HDDs/SSDs/USB flash drives/etc.).
    - mindajar 10y ago
- scarface74 10y ago
  Is ZFS lightweight enough to run on the watch? Their ultimate goal was to have a file system efficient enough and flexible enough to run across all of their OS's - MacOS, iOS, tvOs, and watchOS
  - toast0 10y ago
    The Apple watch has 8 GB of storage and 512 Mb of ram; I don't think that's an unreasonable ratio. Most people discussing zfs memory use have large arrays or deduplication enabled; I'm not sure why dedup would be very useful on a watch. Maybe CPU for checksums is an issue? Apple could probably add acceleration for the checksum algorithm/use an algorithm that was faster/skip the checksums on read + do a sweep when plugged in and fully charged. An 8gb sad only takes minutes to do a complete read, as opposed to a large rotational drive, so you would likely be able to do a full scan in a reasonable amount of time.
  - ahl 10y ago
    Unclear, but a member of the ZFS development team at Apple told me that Giampaolo complained that ZFS would never work on the phone. So the team demonstrated it working on the phone. I know of no obstacles to making it work on the watch other than engineering.
    - blumentopf 10y ago
      So they still have a team working on ZFS? Could the anonymous "ilovezfs" involved with OpenZFSonOSX and coming from a California IP address be part of this team?
- millstone 10y ago
  APFS is targeted to run on low-powered devices like the Apple Watch. It may be that the alternatives cannot be made suitable for such devices: ZFS is famously memory hungry, HAMMER says it's not designed for < 50GB devices.
  - michaelmrose 10y ago
    ZFS requires a lot of ram to enable on line deduplication. From Freebsd Mastery: ZFS Pg 135 "For a rough-and-dirty approximation, you can assume that 1 TB of deduplicated data uses about 5 GB of RAM. You can more closely approximate memory needs for your particular data by looking at your data pool and doing some math. We recommend always doing the math and computing how much RAM your data needs, then using the most pessimistic result. If the math gives you a number above 5 GB, use your math. If not, assume 5 GB per terabyte." Otherwise I think this is like the myth that ZFS requires expensive ECC ram whereas ECC ram is recommended for any filesystem and zfs needs it no more nor less.
    - vvhn 10y ago
      From the 2nd edition of "The Design and Implementation of the FreeBSD Operating System" ZFS, Pg 549 " However it is not designed for or well suited to run on resource constrained systems using 32 bit CPUs with less than 8 Gbyte of memory and one small nearly full disk, which is typical of many embedded systems "
      - michaelmrose 10y ago
        Even mobile cpus will be all 64 bit before long and it seemed to run great with 4gb others reported success on systems with 2gb. Meanwhile ram available in all sorts of devices is ever increasing. What fs a laptop/workstation uses shouldn't be determined by whats suitable for a watch in 2016.
- comex 10y ago
  > Either way, we will now have yet another filesystem to contend with, implement in non-Darwin kernels (maybe), and this adds to the overall support overhead of all operating systems that want to be compatible with Apple devices. On the other hand, if Apple decides to open source the APFS implementation (hard to tell what their plans are from current statements, but I'm holding out hope), it'll probably be under a permissive license that allows porting to Linux. The implementation is in C (not C++) so porting is probably generally feasible. Compare to ZFS, which, even if some distros have finally started shipping it, will never quite be free of licensing issues unless Oracle does a 180.
- vvhn 10y ago
  >and this adds to the overall support overhead of all operating systems that want to be compatible with Apple devices. What operating systems describe tremselves as being "compatible with Apple devices" > Since the older versions of macOS (OSX) don't support APFS, only HFS+, this means Apple and others will also have to continue supporting HFS+. Who else actually "supports" HFS+ ? Sure there are linux "ports" based on the spec but nobody claims them as being "supported". Apple would have had to continue supporting HFS+ whether they chose to implement ZFS, btrfs or HAMMER. >It just seems wasteful of everyone's time to me. I don't know how Apple writing their own filesystem is wasteful of anybody else's time ( except possibly Apple's and/or Disk utility software for vendors for OS X) >Also: https://xkcd.com/927/ https://xkcd.com/927/ The standard is the interface ( POSIX / SUS ) and unless APFS breaks that how is this applicable ?
  - idorosen 10y ago
    > What operating systems describe tremselves as being "compatible with Apple devices" I was referring to the Linux kernel modules implementing HFS+ and other Apple FSes. > Who else actually "supports" HFS+ ? Sure there are linux "ports" based on the spec but nobody claims them as being "supported". Yes, by support I meant other developers who want to be able to read and write to devices in APFS format. > Apple would have had to continue supporting HFS+ whether they chose to implement ZFS, btrfs or HAMMER. Yes, Apple would have to continue supporting HFS+, but other kernel developers would not have to port yet another filesystem (APFS) with all of its own quirks; and, who knows, maybe it would be less work for Apple to inherit ZFS/btrfs/HAMMER/some other filesystem's solutions to some of the same problems they're trying to solve from scratch here. My point was more that by reinventing the wheel to implement some of these features, they've created not just more work for themselves potentially, but more for the open source kernel development community as well in the long run. > I don't know how Apple writing their own filesystem is wasteful of anybody else's time ( except possibly Apple's and/or Disk utility software for vendors for OS X) APFS will find its way to external HDDs/SSDs/flash drives, etc., then in order to read those filesystems someone else will have to port it to any other devices/readers of that device/FS. > The standard is the interface ( POSIX / SUS ) and unless APFS breaks that how is this applicable ? I didn't mention POSIX, VFS, or filesystem _interfaces_. The analogy to the XKCD strip was that we already had N filesystems that have a large subset of (or in some cases superset of) the features of APFS as of right now, now we have N+1 complex filesystems to contend with and port and interoperate with in other kernels/OSes (mainly Linux + non-Darwin BSDs). This may just be the price of progress, which is fine. I think it'll be fantastic if Apple makes progress in this area and improves upon the work of others. The developer seemed to be ignoring history so as not to "taint" himself (did he mean IP/legally tainted?), which is slightly worrying to me. I hope Apple open sources their implementation under a BSD/GPL dual license to make it easier for others to port it directly into other kernels, rather than having to reimplement it themselves.
niftich 10y ago
The file-level deduplication [1] is interesting. Not being a filesystem expert, this sounds like it fulfills a similar usecase to snapshots [2]. Or am I reading this wrong? Is NTFS's shadow copy like Snapshots? [1] http://dtrace.org/blogs/ahl/2016/06/19/apfs-part3/#apfs-clones http://dtrace.org/blogs/ahl/2016/06/19/apfs-part3/#apfs-clon... [2] http://dtrace.org/blogs/ahl/2016/06/19/apfs-part2/#apfs-snapshots http://dtrace.org/blogs/ahl/2016/06/19/apfs-part2/#apfs-snap...
- rincebrain 10y ago
  NTFS Shadow Copies are more like LVM/ZFS snapshots than APFS's file-level CoW snapshots, in that they both operate on the entire volume at block-level, rather than having a per-file level of granularity. There are other FSes that allow the behavior that APFS is demonstrating - look at OCFS2 and Btrfs, both of which allow you to do cp --reflink.
TazeTSchnitzel 10y ago
> Also, APFS removes the most common way of a user achieving local data redundancy: copying files. A copied file in APFS actually creates a lightweight clone with no duplicated data. No, it doesn't. APFS supports copying files, if you want that. It's just that the default in Finder is to make a “clone” (copy-on-write).
- ahl 10y ago
  Fair enough; and right now cp doesn't use the fast clone functionality, but it assuredly will. I'm not sure 'cat <file >file.dup' is reasonable for most users.
  - ghshephard 10y ago
    Just teach everyone to use dd instead - dd if=file of=file.dup :-)
  - TazeTSchnitzel 10y ago
    If they patched it to use a different syscall, maybe.
veidr 10y ago
What a great and valuable post, especially since this info is the result of talking to the APFS team at WWDC, and has not been published anywhere else yet. Of particular interest (to me) was the "Checksums" section: Notably absent from the APFS intro talk was any mention of checksums....APFS checksums its own metadata but not user data. ...The APFS engineers I talked to cited strong ECC protection within Apple storage devices. Both flash SSDs and magnetic media HDDs use redundant data to detect and correct errors. The engineers contend that Apple devices basically don’t return bogus data. That is utterly disappointing. SSDs have internal checksums, sure, but there are so many different ways and different points at which a bit can be flipped. It's hard for me to imagine a worse starting point to conceive a new filesystem than "let's assume our data storage devices are perfect, and never have any faulty components or firmware bugs". ZFS has a lot of features, but data integrity is the feature. I get that maybe a checksumming filesystem could conceivably be too computationally expensive for the little jewelry-computers Apple is into these days, but it's a terrible omission on something that is supposed to be the new filesystem for macOS.
- mahyarm 10y ago
  External hard drives / SSDs that are using APFS? I thought that would be a pretty obvious use case.
- codemac 10y ago
  Checksums are usually very fast to compute as the ARM CPUs of any modern phone have crypto engines, and their laptops do as well. I think trading data protection for performance reasons would be pretty irrational.
  - cm3 10y ago
    Except that with NVME drives, and the parallel operations you can run on these, the performance of checksums becomes important again. Recent experiments with HAMMER2: https://www.dragonflydigest.com/2016/06/15/18281.html https://www.dragonflydigest.com/2016/06/15/18281.html
    - 10y ago
sho_hn 10y ago
I'm extremely confused by this: > With APFS, if you copy a file within the same file system (or possibly the same container; more on this later), no data is actually duplicated. [...] I haven’t see this offered in other file systems [...] To my knowledge, this is what cp --reflink does on GNU/Linux on a supporting filesystem, most notably btrfs, and has been doing by default in newer combinations of the kernel and GNU coreutils. This guy seems too well-informed and experienced in the domain to miss something so obvious, though. So what am I missing? Also interesting to me is the paragraph about prioritizing certain I/O requests to optimize interactive latency: On Linux this is done by the I/O scheduler, exchangable and agnostic to the filesystem. Perhaps greater insight into the filesystem could aid I/O scheduling (this has been the argument for moving RAID code into filesystems as well, though, which APFS opts against) -- hearing a well-informed opinion on this point would be interesting. Unless this post gets it wrong and I/O scheduling isn't technically implemented in APFS either. It seems like this perspective might be one written from within a Solaris/ZFS bubble and further hamstrung by macOS' closed-source development model. Which is interesting in light of the Giampaolo quote about intentionally not looking closely at the competition, either.
- ahl 10y ago
  This guy (i.e. me) wasn't aware of this functionality in btrfs. Are reflinks commonly used? Yes, I know more about ZFS than the other filesystems mentioned.
- e12e 10y ago
  I wasn't aware of --reflink either, apparently support is coming to XFS as well (at some point): https://pkalever.wordpress.com/2016/01/22/xfs-reflinks-tutorial/ https://pkalever.wordpress.com/2016/01/22/xfs-reflinks-tutor...
- deleted 10y ago
  [deleted]
- pixelbeat 10y ago
  Note mv tries reflink by default (when moving files across BTRFS subvols) since doesn't need a separate copy of the data. Now as storage systems evolve there are less guarantees that one does get multiple copies, with deduplicating at lower layers etc., and therefore cp may change at some stage to reflinking by default, especially as clone_file_range() moves to the VFS level. Actual data redundancy would then achieved at a higher level with separate file systems, devices, data centers, ... where arguably it needs to happen now anyway.
amluto 10y ago
> I get that maybe a checksumming filesystem could conceivably be too computationally expensive for the little jewelry-computers Apple is into these days, but it's a terrible omission on something that is supposed to be the new filesystem for macOS. Checksumming has another cost that isn't immediately obvious. Suppose you write to a file and the writes are cached. Then the filesystem starts to flush to disk. On a conventional filesystem, you can keep writing to the dirty page while the disk DMAs data out of it. On a checksumming filesystem, you can't: you have to compute the checksum and then write out data consistent with the checksum. This means you either have to delay user code that tries to write, or you have to copy the page, or you need hardware support for checksumming while writing. On Linux, this type of delay is called "stable pages", and it destroys performance on some workloads on btrfs.
- sangnoir 10y ago
  For desktop computing, I'll take data integrity over good 'performance' any day. The use-cases for iDevices might be different, coloring Apples perspective.
maureenash 10y ago
APFS makes no claims with regard to data redundancy. As Apple's Eric Tamura noted at WWDC, most Apple devices have a single storage. A file system is method used by a computer to store and retrieve data.Custom essay writing service (http://www.essayguardian.com/ http://www.essayguardian.com/) helps to reduce your workload while writing dissertation proposal and meets all your requirements.
gmac 10y ago
Slightly worried by the vibe that comes off this. "I asked him about looking for inspiration in other modern file systems ... he was aware of them, but didn’t delve too deeply for fear, he said, of tainting himself". And (to paraphrase): 'bit-rot? What's that?'. I would have hoped that a new filesystem with such wide future adoption would have come from a roomful of smart people with lots of experience of (for example) contributing to various modern filesystems, understanding their strengths and weaknesses, and dealing with data corruption issues in the field. This doesn't come across that way at all.
- kev009 10y ago
  Not looking at HAMMER/HAMMER2 is just NIH too, no 'taint' from BSD as Apple should well know on their UNIX side.
- cm3 10y ago
  Given Dominic's other output, I'm going to believe there's more to the story because he didn't strike me as someone who would actively ignore past innovations. I know it's a popular concept to NIH stuff when devs believe they know enough to build it, but so much stuff is just built poorly without consideration for existing designs and it shows in the poor software we have to live with.
ghshephard 10y ago
For example, my 1TB SSD includes 1TB (2^30 = 1024^3) bytes of flash but only reports 931GB of available space, sneakily matching the storage industry’s self-serving definition of 1TB (1000^3 = 1 trillion bytes). Great article, but a couple nitpicking corrections (which seem appropriate for a storage article) Per: https://en.wikipedia.org/wiki/Terabyte https://en.wikipedia.org/wiki/Terabyte - Terabyte is 1000^4, not 1000^3. Also It's been 6+ years since we all agreed that TiB means 2^40 or 1024^4, and TB means 10^12. Indeed, only in the case of memory does "T" ever mean 2^40 anyways. It's always been the case that in both data rates, as well as storage, that T means 10^12. This convention is strong enough that we most of us just have thrown up our hands and agree when referring to DRAM memory, that Terabyte will mean 1024^4, and 1000^4 everywhere else. Indeed, in the rare case where someone uses TiB to refer to a data rate, they are almost without exception incorrectly using it, and, they actually mean TB.
amelius 10y ago
I think the value of this new proprietary filesystem is limited, since you can't run it on servers (Apple does not make servers anymore). Also, compatibility/porting issues may become a problem if you build your software for it.
cm3 10y ago
I'm still looking for a widely supported (at least FreeBSD and Linux kernels) filesystem for external drives to carry around that doesn't have the FAT32 limitations. There's exFAT but no stable and supported implementation. Then there's NTFS, but that's also not 100% reliable in my experience when used through FUSE (NTFS-3G). I've considered UFS but that also was a no go. I'm hopeful for lklfuse[1] that also runs on FreeBSD and givess access to ext4, xfs, etc. in a way like Rump and allows you to use the same drivers on FreeBSD. I'm cautious though, given that I don't want corrupted data I might notice too late. Let's see if lklfuse provides LUKS as well, otherwise Dragonfly's LUKS implementation might need to be ported to FreeBSD or something like that. External drives one might lose need to be encrypted. [1] https://www.freshports.org/sysutils/fusefs-lkl/ https://www.freshports.org/sysutils/fusefs-lkl/
- drvdevd 10y ago
  Thanks for this! I didn't realize (or had forgotten) LUKS had been ported to Dragonfly. Also you touch upon my #1 frustration with APFS without really knowing anything about it: simple portability.
  - cm3 10y ago
    Yeah, I believe it's by the same Dragonfly developer who also wrote tcplay[1] for TrueCrypt volumes. [1] https://leaf.dragonflybsd.org/cgi/web-man?command=tcplay&section=8 https://leaf.dragonflybsd.org/cgi/web-man?command=tcplay&sec...

237 points by knweiss 10y ago

In my opinion, APFS does not seem to improve upon ZFS in several key areas (compression, sending/receiving snapshots, dedup, etc.). Apple is reimplementing many features already implemented in OpenZFS, btrfs (which itself reimplemented a lot of ZFS features), BSD HAMMER, etc. Maybe extending one of these existing filesystems to add any functionality Apple needs on top of its existing features (and, hopefully, contributing that back to the open source implementation) would cost more person-hours than implementing APFS from scratch. Maybe not. Either way, we will now have yet another filesystem to contend with, implement in non-Darwin kernels (maybe), and this adds to the overall support overhead of all operating systems that want to be compatible with Apple devices. Since the older versions of macOS (OSX) don't support APFS, only HFS+, this means Apple and others will also have to continue supporting HFS+. It just seems wasteful of everyone's time to me. Also: https://xkcd.com/927/ https://xkcd.com/927/

lanna 10y ago
Breaking changes sometimes are unavoidable, progress has to be made.
matthewmcg 10y ago
Agreed. A few years ago Apple was on the verge of using ZFS but cancelled the project due to licensing issues. See http://arstechnica.com/apple/2009/10/apple-abandons-zfs-on-mac-os-x-project-over-licensing-issues/ http://arstechnica.com/apple/2009/10/apple-abandons-zfs-on-m...
- snarf 10y ago
  A better/more up to date article on this from the same blog as this item: http://dtrace.org/blogs/ahl/2016/06/15/apple_and_zfs/ http://dtrace.org/blogs/ahl/2016/06/15/apple_and_zfs/
mindajar 10y ago
Classic comic, but I don't think it applies. APFS looks intended to solve Apple's product problems really well, and it doesn't even try to be a filesystem for everyone. Apple has said from time to time that they're all about owning and controlling the key technologies that go into their products. APFS makes a lot of sense from that perspective, and this seems one of those cases where going their own way is better than importing someone else's constraints. ZFS on an Apple Watch? LOL.
- tfar 10y ago
  I would not be surprised if one could write a ZFS implementation optimized for more constrained devices. If you already know you are going to a have flash storage you can probably ditch some of the N layers of cache you see in common ZFS implementations. Not that ZFS is a one size fits all, but the file systems specification could be implemented in more than one way.
  - mindajar 10y ago
    If you assume Apple cares about having a disk format in common with other platforms, sure, I'd agree that's probably possible. But I don't think they do; they seem to care a lot more about things like a unified codebase across their platforms, the energy-efficiency initiatives they've been pushing for a few years, owning the key tech in the products, etc. One slide in the WWDC talk deck showed a bunch of divergent Apple storage technologies across all their platforms that are being replaced by APFS. If ZFS has to fork into weird variants to run well on the phone or watch, that seems less appealing than a single codebase optimized for just the stuff Apple products do.
- idorosen 10y ago
  Should have said s/standards/filesystems/g... :-) I was reacting to the idea of APFS for macOS, as well as having yet another filesystem to deal with on external media that interacts with multiple computers (HDDs/SSDs/USB flash drives/etc.).
  - mindajar 10y ago
scarface74 10y ago
Is ZFS lightweight enough to run on the watch? Their ultimate goal was to have a file system efficient enough and flexible enough to run across all of their OS's - MacOS, iOS, tvOs, and watchOS
- toast0 10y ago
  The Apple watch has 8 GB of storage and 512 Mb of ram; I don't think that's an unreasonable ratio. Most people discussing zfs memory use have large arrays or deduplication enabled; I'm not sure why dedup would be very useful on a watch. Maybe CPU for checksums is an issue? Apple could probably add acceleration for the checksum algorithm/use an algorithm that was faster/skip the checksums on read + do a sweep when plugged in and fully charged. An 8gb sad only takes minutes to do a complete read, as opposed to a large rotational drive, so you would likely be able to do a full scan in a reasonable amount of time.
- ahl 10y ago
  Unclear, but a member of the ZFS development team at Apple told me that Giampaolo complained that ZFS would never work on the phone. So the team demonstrated it working on the phone. I know of no obstacles to making it work on the watch other than engineering.
  - blumentopf 10y ago
    So they still have a team working on ZFS? Could the anonymous "ilovezfs" involved with OpenZFSonOSX and coming from a California IP address be part of this team?
millstone 10y ago
APFS is targeted to run on low-powered devices like the Apple Watch. It may be that the alternatives cannot be made suitable for such devices: ZFS is famously memory hungry, HAMMER says it's not designed for < 50GB devices.
- michaelmrose 10y ago
  ZFS requires a lot of ram to enable on line deduplication. From Freebsd Mastery: ZFS Pg 135 "For a rough-and-dirty approximation, you can assume that 1 TB of deduplicated data uses about 5 GB of RAM. You can more closely approximate memory needs for your particular data by looking at your data pool and doing some math. We recommend always doing the math and computing how much RAM your data needs, then using the most pessimistic result. If the math gives you a number above 5 GB, use your math. If not, assume 5 GB per terabyte." Otherwise I think this is like the myth that ZFS requires expensive ECC ram whereas ECC ram is recommended for any filesystem and zfs needs it no more nor less.
  - vvhn 10y ago
    From the 2nd edition of "The Design and Implementation of the FreeBSD Operating System" ZFS, Pg 549 " However it is not designed for or well suited to run on resource constrained systems using 32 bit CPUs with less than 8 Gbyte of memory and one small nearly full disk, which is typical of many embedded systems "
    - michaelmrose 10y ago
      Even mobile cpus will be all 64 bit before long and it seemed to run great with 4gb others reported success on systems with 2gb. Meanwhile ram available in all sorts of devices is ever increasing. What fs a laptop/workstation uses shouldn't be determined by whats suitable for a watch in 2016.
comex 10y ago
> Either way, we will now have yet another filesystem to contend with, implement in non-Darwin kernels (maybe), and this adds to the overall support overhead of all operating systems that want to be compatible with Apple devices. On the other hand, if Apple decides to open source the APFS implementation (hard to tell what their plans are from current statements, but I'm holding out hope), it'll probably be under a permissive license that allows porting to Linux. The implementation is in C (not C++) so porting is probably generally feasible. Compare to ZFS, which, even if some distros have finally started shipping it, will never quite be free of licensing issues unless Oracle does a 180.
vvhn 10y ago
>and this adds to the overall support overhead of all operating systems that want to be compatible with Apple devices. What operating systems describe tremselves as being "compatible with Apple devices" > Since the older versions of macOS (OSX) don't support APFS, only HFS+, this means Apple and others will also have to continue supporting HFS+. Who else actually "supports" HFS+ ? Sure there are linux "ports" based on the spec but nobody claims them as being "supported". Apple would have had to continue supporting HFS+ whether they chose to implement ZFS, btrfs or HAMMER. >It just seems wasteful of everyone's time to me. I don't know how Apple writing their own filesystem is wasteful of anybody else's time ( except possibly Apple's and/or Disk utility software for vendors for OS X) >Also: https://xkcd.com/927/ https://xkcd.com/927/ The standard is the interface ( POSIX / SUS ) and unless APFS breaks that how is this applicable ?
- idorosen 10y ago
  > What operating systems describe tremselves as being "compatible with Apple devices" I was referring to the Linux kernel modules implementing HFS+ and other Apple FSes. > Who else actually "supports" HFS+ ? Sure there are linux "ports" based on the spec but nobody claims them as being "supported". Yes, by support I meant other developers who want to be able to read and write to devices in APFS format. > Apple would have had to continue supporting HFS+ whether they chose to implement ZFS, btrfs or HAMMER. Yes, Apple would have to continue supporting HFS+, but other kernel developers would not have to port yet another filesystem (APFS) with all of its own quirks; and, who knows, maybe it would be less work for Apple to inherit ZFS/btrfs/HAMMER/some other filesystem's solutions to some of the same problems they're trying to solve from scratch here. My point was more that by reinventing the wheel to implement some of these features, they've created not just more work for themselves potentially, but more for the open source kernel development community as well in the long run. > I don't know how Apple writing their own filesystem is wasteful of anybody else's time ( except possibly Apple's and/or Disk utility software for vendors for OS X) APFS will find its way to external HDDs/SSDs/flash drives, etc., then in order to read those filesystems someone else will have to port it to any other devices/readers of that device/FS. > The standard is the interface ( POSIX / SUS ) and unless APFS breaks that how is this applicable ? I didn't mention POSIX, VFS, or filesystem _interfaces_. The analogy to the XKCD strip was that we already had N filesystems that have a large subset of (or in some cases superset of) the features of APFS as of right now, now we have N+1 complex filesystems to contend with and port and interoperate with in other kernels/OSes (mainly Linux + non-Darwin BSDs). This may just be the price of progress, which is fine. I think it'll be fantastic if Apple makes progress in this area and improves upon the work of others. The developer seemed to be ignoring history so as not to "taint" himself (did he mean IP/legally tainted?), which is slightly worrying to me. I hope Apple open sources their implementation under a BSD/GPL dual license to make it easier for others to port it directly into other kernels, rather than having to reimplement it themselves.

niftich 10y ago

The file-level deduplication [1] is interesting. Not being a filesystem expert, this sounds like it fulfills a similar usecase to snapshots [2]. Or am I reading this wrong? Is NTFS's shadow copy like Snapshots? [1] http://dtrace.org/blogs/ahl/2016/06/19/apfs-part3/#apfs-clones http://dtrace.org/blogs/ahl/2016/06/19/apfs-part3/#apfs-clon... [2] http://dtrace.org/blogs/ahl/2016/06/19/apfs-part2/#apfs-snapshots http://dtrace.org/blogs/ahl/2016/06/19/apfs-part2/#apfs-snap...

rincebrain 10y ago
NTFS Shadow Copies are more like LVM/ZFS snapshots than APFS's file-level CoW snapshots, in that they both operate on the entire volume at block-level, rather than having a per-file level of granularity. There are other FSes that allow the behavior that APFS is demonstrating - look at OCFS2 and Btrfs, both of which allow you to do cp --reflink.

TazeTSchnitzel 10y ago

> Also, APFS removes the most common way of a user achieving local data redundancy: copying files. A copied file in APFS actually creates a lightweight clone with no duplicated data. No, it doesn't. APFS supports copying files, if you want that. It's just that the default in Finder is to make a “clone” (copy-on-write).

ahl 10y ago
Fair enough; and right now cp doesn't use the fast clone functionality, but it assuredly will. I'm not sure 'cat <file >file.dup' is reasonable for most users.
- ghshephard 10y ago
  Just teach everyone to use dd instead - dd if=file of=file.dup :-)
- TazeTSchnitzel 10y ago
  If they patched it to use a different syscall, maybe.

veidr 10y ago

What a great and valuable post, especially since this info is the result of talking to the APFS team at WWDC, and has not been published anywhere else yet. Of particular interest (to me) was the "Checksums" section: Notably absent from the APFS intro talk was any mention of checksums....APFS checksums its own metadata but not user data. ...The APFS engineers I talked to cited strong ECC protection within Apple storage devices. Both flash SSDs and magnetic media HDDs use redundant data to detect and correct errors. The engineers contend that Apple devices basically don’t return bogus data. That is utterly disappointing. SSDs have internal checksums, sure, but there are so many different ways and different points at which a bit can be flipped. It's hard for me to imagine a worse starting point to conceive a new filesystem than "let's assume our data storage devices are perfect, and never have any faulty components or firmware bugs". ZFS has a lot of features, but data integrity is the feature. I get that maybe a checksumming filesystem could conceivably be too computationally expensive for the little jewelry-computers Apple is into these days, but it's a terrible omission on something that is supposed to be the new filesystem for macOS.

mahyarm 10y ago
External hard drives / SSDs that are using APFS? I thought that would be a pretty obvious use case.
codemac 10y ago
Checksums are usually very fast to compute as the ARM CPUs of any modern phone have crypto engines, and their laptops do as well. I think trading data protection for performance reasons would be pretty irrational.
- cm3 10y ago
  Except that with NVME drives, and the parallel operations you can run on these, the performance of checksums becomes important again. Recent experiments with HAMMER2: https://www.dragonflydigest.com/2016/06/15/18281.html https://www.dragonflydigest.com/2016/06/15/18281.html
  - 10y ago

sho_hn 10y ago

I'm extremely confused by this: > With APFS, if you copy a file within the same file system (or possibly the same container; more on this later), no data is actually duplicated. [...] I haven’t see this offered in other file systems [...] To my knowledge, this is what cp --reflink does on GNU/Linux on a supporting filesystem, most notably btrfs, and has been doing by default in newer combinations of the kernel and GNU coreutils. This guy seems too well-informed and experienced in the domain to miss something so obvious, though. So what am I missing? Also interesting to me is the paragraph about prioritizing certain I/O requests to optimize interactive latency: On Linux this is done by the I/O scheduler, exchangable and agnostic to the filesystem. Perhaps greater insight into the filesystem could aid I/O scheduling (this has been the argument for moving RAID code into filesystems as well, though, which APFS opts against) -- hearing a well-informed opinion on this point would be interesting. Unless this post gets it wrong and I/O scheduling isn't technically implemented in APFS either. It seems like this perspective might be one written from within a Solaris/ZFS bubble and further hamstrung by macOS' closed-source development model. Which is interesting in light of the Giampaolo quote about intentionally not looking closely at the competition, either.

ahl 10y ago
This guy (i.e. me) wasn't aware of this functionality in btrfs. Are reflinks commonly used? Yes, I know more about ZFS than the other filesystems mentioned.
e12e 10y ago
I wasn't aware of --reflink either, apparently support is coming to XFS as well (at some point): https://pkalever.wordpress.com/2016/01/22/xfs-reflinks-tutorial/ https://pkalever.wordpress.com/2016/01/22/xfs-reflinks-tutor...
deleted 10y ago
[deleted]
pixelbeat 10y ago
Note mv tries reflink by default (when moving files across BTRFS subvols) since doesn't need a separate copy of the data. Now as storage systems evolve there are less guarantees that one does get multiple copies, with deduplicating at lower layers etc., and therefore cp may change at some stage to reflinking by default, especially as clone_file_range() moves to the VFS level. Actual data redundancy would then achieved at a higher level with separate file systems, devices, data centers, ... where arguably it needs to happen now anyway.

amluto 10y ago

> I get that maybe a checksumming filesystem could conceivably be too computationally expensive for the little jewelry-computers Apple is into these days, but it's a terrible omission on something that is supposed to be the new filesystem for macOS. Checksumming has another cost that isn't immediately obvious. Suppose you write to a file and the writes are cached. Then the filesystem starts to flush to disk. On a conventional filesystem, you can keep writing to the dirty page while the disk DMAs data out of it. On a checksumming filesystem, you can't: you have to compute the checksum and then write out data consistent with the checksum. This means you either have to delay user code that tries to write, or you have to copy the page, or you need hardware support for checksumming while writing. On Linux, this type of delay is called "stable pages", and it destroys performance on some workloads on btrfs.

sangnoir 10y ago
For desktop computing, I'll take data integrity over good 'performance' any day. The use-cases for iDevices might be different, coloring Apples perspective.

maureenash 10y ago

APFS makes no claims with regard to data redundancy. As Apple's Eric Tamura noted at WWDC, most Apple devices have a single storage. A file system is method used by a computer to store and retrieve data.Custom essay writing service (http://www.essayguardian.com/ http://www.essayguardian.com/) helps to reduce your workload while writing dissertation proposal and meets all your requirements.

gmac 10y ago

Slightly worried by the vibe that comes off this. "I asked him about looking for inspiration in other modern file systems ... he was aware of them, but didn’t delve too deeply for fear, he said, of tainting himself". And (to paraphrase): 'bit-rot? What's that?'. I would have hoped that a new filesystem with such wide future adoption would have come from a roomful of smart people with lots of experience of (for example) contributing to various modern filesystems, understanding their strengths and weaknesses, and dealing with data corruption issues in the field. This doesn't come across that way at all.

kev009 10y ago
Not looking at HAMMER/HAMMER2 is just NIH too, no 'taint' from BSD as Apple should well know on their UNIX side.
cm3 10y ago
Given Dominic's other output, I'm going to believe there's more to the story because he didn't strike me as someone who would actively ignore past innovations. I know it's a popular concept to NIH stuff when devs believe they know enough to build it, but so much stuff is just built poorly without consideration for existing designs and it shows in the poor software we have to live with.

ghshephard 10y ago

For example, my 1TB SSD includes 1TB (2^30 = 1024^3) bytes of flash but only reports 931GB of available space, sneakily matching the storage industry’s self-serving definition of 1TB (1000^3 = 1 trillion bytes). Great article, but a couple nitpicking corrections (which seem appropriate for a storage article) Per: https://en.wikipedia.org/wiki/Terabyte https://en.wikipedia.org/wiki/Terabyte - Terabyte is 1000^4, not 1000^3. Also It's been 6+ years since we all agreed that TiB means 2^40 or 1024^4, and TB means 10^12. Indeed, only in the case of memory does "T" ever mean 2^40 anyways. It's always been the case that in both data rates, as well as storage, that T means 10^12. This convention is strong enough that we most of us just have thrown up our hands and agree when referring to DRAM memory, that Terabyte will mean 1024^4, and 1000^4 everywhere else. Indeed, in the rare case where someone uses TiB to refer to a data rate, they are almost without exception incorrectly using it, and, they actually mean TB.

amelius 10y ago

I think the value of this new proprietary filesystem is limited, since you can't run it on servers (Apple does not make servers anymore). Also, compatibility/porting issues may become a problem if you build your software for it.

cm3 10y ago

I'm still looking for a widely supported (at least FreeBSD and Linux kernels) filesystem for external drives to carry around that doesn't have the FAT32 limitations. There's exFAT but no stable and supported implementation. Then there's NTFS, but that's also not 100% reliable in my experience when used through FUSE (NTFS-3G). I've considered UFS but that also was a no go. I'm hopeful for lklfuse[1] that also runs on FreeBSD and givess access to ext4, xfs, etc. in a way like Rump and allows you to use the same drivers on FreeBSD. I'm cautious though, given that I don't want corrupted data I might notice too late. Let's see if lklfuse provides LUKS as well, otherwise Dragonfly's LUKS implementation might need to be ported to FreeBSD or something like that. External drives one might lose need to be encrypted. [1] https://www.freshports.org/sysutils/fusefs-lkl/ https://www.freshports.org/sysutils/fusefs-lkl/

drvdevd 10y ago
Thanks for this! I didn't realize (or had forgotten) LUKS had been ported to Dragonfly. Also you touch upon my #1 frustration with APFS without really knowing anything about it: simple portability.
- cm3 10y ago
  Yeah, I believe it's by the same Dragonfly developer who also wrote tcplay[1] for TrueCrypt volumes. [1] https://leaf.dragonflybsd.org/cgi/web-man?command=tcplay&section=8 https://leaf.dragonflybsd.org/cgi/web-man?command=tcplay&sec...