Slashdot Mirror
Apple Introduces New File System AFPS With Tons Of 'Solid' Features (apple.com)
On the sidelines of its Worldwide Developer's Conference, Apple also quietly unveiled a new file system dubbed APFS (Apple File System). Here's how the company describes it: HFS+ and its predecessor HFS are more than 30 years old. These file systems were developed in an era of floppy disks and spinning hard drives, where file sizes were calculated in kilobytes or megabytes. Today, solid-state drives store millions of files, accounting for gigabytes or terabytes of data. There is now also a greater importance placed on keeping sensitive information secure and safe from prying eyes. A new file system is needed to meet the current needs of Apple products, and support new technologies for decades to come.Ars Technica dived into the documentation to find that APFS comes with a range of "solid" features including support for 64-bit inode numbering, and improved granularity of object time-stamping. "APFS supports nanosecond time stamp granularity rather than the 1-second time stamp granularity in HFS+." It also supports copy-on-write metadata scheme which aims to ensure that file system commits and writes to the file system journal stay in sync even if "something happens during the write -- like if the system loses power." The new file system offers an improvement over Apple's previous full-disk encryption File Vault application. It also features Snapshots (that lets you throw off a read-only instant of a file system at any given point in time), and Clones. According to the documentation, APFS can create file or directory clones -- and like a proper next-generation file system, it does so instantly, rather than having to wait for data to be copied. From the report: Also interesting is the concept of "space sharing," where multiple volumes can be created out of the same chunk of underlying physical space. This sounds on first glance a lot like enterprise-style thin provisioning, where you can do things like create four 1TB volumes on a single 1TB disk, and each volume grows as space is added to it. You can add physical storage to keep up with the volume's growth without having to resize the logical volume.As the documentation notes, things are in early stage, so it might take a while before AFPS becomes available to general users.
This new filesystem should become stable in about 2028.
C'mon, it's 2016. Where is compression?
It's a hard job. We're into year fifteen of ZFS and it's just starting to gain some features that make administration of it manageable by non-experts. Give it another five before you want to make it your default on a desktop for grandma. BTRFS will be along five years after that.
If Apple can pull off something similar in a couple years, it will be a major triumph. It's too bad for everybody that Steve got bitchy at Jonathan and the community hasn't had Apple's help as a contributor for the past decade.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I'm glad Apple has introduced this. As of now, the snapshot API and others are not present, but now Apple is on parity with everyone else in the industry.
APFS isn't like ZFS or btrfs, but more like ReFS in the fact that it still requires a logical volume manager. It would be nice if it had RAID, but that is a minor item, compared to just getting rid of HFS+, which just had to be killed.
Some features I like:
The ability to encrypt volumes with multiple volume keys. It looks like it will be similar to Oracle's ZFS on Solaris, but the implementation can be completely different.
Snapshots. Something like zfs send and zfs send -i will be quite useful for backups.
Copy-on-write capability, which is useful for VMs.
Of course, it appears that Apple will be documenting and publishing the FS's specs in 2017, which will be even more useful for compatibility.
All and all, even though there is no RAID 5/RAID-Z, or LVM replacement, this is a heck of a lot better than what OS X/macOS has now.
Licensing. Apple did flirt with ZFS, but for some reason, and I would guess it was license issues, they decided not to go that route. Using btrfs would bring GPL/BSD licensing issues. So, Apple either had to license something like ReFS from MS, or roll their own.
Lack of backwards compatibility is the issue. You shouldn't have to refactor your entire code base once a year (oh and Xcode doesn't support Swift refactoring). That is the gripe. Move the language forward, don't break it yearly. Swift is a nice language, I enjoy using it, but this is a big issue.
Swift 2 is stable enough that I get occasional calls from recruiters asking for five years of it as a language for dev jobs. So, if it is good enough to transcend time/space, it should be stable enough.
ZFS is under CDDL and would not even need to be "licensed" in the usual sense — it is free for anybody to take. "Too free" for certain zealots, in fact, which is why it was not part of Linux kernel for a while — until the supposed "license incompatibility" myths got debunked.
Even Linux now offers ZFS — Apple would've had a much easier time porting it, because MacOS is already FreeBSD-based and the FreeBSD-project had ZFS available "out of the box" for several major releases spanning many years.
What did Apple find lacking about ZFS, that would justify creating their own, is, indeed, a mystery. Probably, a case of the Not Invented Here Syndrome. Sad...
In Soviet Washington the swamp drains you.
How about letting users unplug removable media without having to eject it first like every other OS has had for about a decade.
Would you want to be licensing anything from Oracle today?
I was hoping Apple would license ZFS or even Veritas Volume Manager/Veritas FS from Symantec.
I thought Veritas was also called Online Journaled File System (OnlineJFS or OJFS). What else is OJFS?
OJFS? Why do you computer types insist on naming your filesystems after murders?
What a ridiculous argument.
By that logic, backwards compatibility is never an issue. Why even try to offer it? You can just keep using the old version! Compatibility solved!
It means you can guarantee that each file has a unique 64-bit timestamp by simply assigning a sequential nanosecond timestamp if two files get written at once. It also gives an opportunity to work around UNIX's year 2038 problem (2^31 UTC seconds since 1970) and Apple's year 2040 problem (2^32 UTC seconds since 1904), pushing it out to at least 2262 (2^63 UTC nanoseconds since 1970).
Well there's ReiserFS. At least there's precedent.
ZFS is not recommended for non-ECC RAM. RAM errors can get propagated to disk by application read operations, not just writes.
http://research.cs.wisc.edu/ad...
It's HR boilerplate. They know nothing about the technology, but they know that for entry level they want degree plus course work in $X, for junior they want 5 years $X, and for senior they want 10 years $X and $Y. I've read a job description for our group once and showed it to my manager asking what position it was for, and he replied "wait, that's not what I wrote!"