What’s New in Apple Filesystems [pdf]
devstreaming-cdn.apple.com
devstreaming-cdn.apple.com
That said, I don't understand the use case for firm links. Seems like the problem it's trying to solve can just be solved with simple mount points: mounting read-write /Users and /usr/local. Am I missing something?
/AppleInternal Device/AppleInternal
/Applications Device/Applications
/Library Device/Library
/System/Library/Caches Device/System/Library/Caches
/System/Library/Assets Device/System/Library/Assets
/System/Library/PreinstalledAssets Device/System/Library/PreinstalledAssets
/System/Library/AssetsV2 Device/System/Library/AssetsV2
/System/Library/PreinstalledAssetsV2 Device/System/Library/PreinstalledAssetsV2
/System/Library/CoreServices/CoreTypes.bundle/Contents/Library Device/System/Library/CoreServices/CoreTypes.bundle/Contents/Library
/System/Library/Speech Device/System/Library/Speech
/Users Users
/Volumes Device/Volumes
/cores Device/cores
/home Device/home
/mnt Device/mnt
/opt Device/opt
/private Device/private
/sw Device/sw
/usr/local Device/usr/local
/usr/libexec/cups Device/usr/libexec/cups
/usr/share/snmp Device/usr/share/snmpHaven't watched the video yet, so I'm speculating. We know APFS doesn't support directory hard links, which means Time Machine can't back up to APFS. I'm guessing firm links are designed to fix this problem (perhaps among others).
I also suspect that will launch 'soon' (after September but possibly in March) , but I have to imagine the complexity and testing requirements for such a in-place migration are staggering.
"Traditionally, it was done by mounting file systems on top of directories in the root file system. With the number of crossing points which we need to introduce and the number of volumes which it would require in the file system, that approach becomes rather expensive."
And the only alternative I hear recommended is xfs which is also around forever but not advanced, zfs is license restricted and btrfs isn't widely used enough to consider using it daily.
It's sad Linux is still stuck with basic file systems without any of the modern features to this day even though there must be huge demand for a more modern file system that can go with kernel GPL2.
ZFS send/receive style volume serialization for replication backup, etc. File system snapshot support included.
iOS or should I say iPadOS supports external USB media and SMB.
What seems to be missing is block level checksumming and integrity checks, scrubbing, block level duplication to protect important files, etc. No whiff of deduplication either, but that might be too memory intensive for Apple's purposes.
The only reason I know this is because the last time I had to upgrade iOS using iTunes - going from iOS 4 to 5, I had three separate devices that required separate downloads for my iPhone 4, iPod Touch, and iPad.
However it is often great for virtual machines and other software development related things, as long as all the underlying block sizes and alignments match.
You really do want strong integrity guarantees though. One corrupted block can cause a lot of damage.
In any case, dedup just makes things more confusing to the customer— like, "you have X GB in files on your computer, but more than N-X GB free space because of magical deduplication." Or worse, "You deleted all those files, but didn't actually free up any space because they were dupes. So sad."
For what it's worth, this can already happen in APFS. While they don't have real deduplication, if you copy a file within Finder, that copy won't take up extra space.
If your application is smarter, then it could just COW one block, whatever the minimum block size is for that file system. e.g. for Btrfs it's page size, so x86 that's 4KiB, ppc64le it's 64KiB. I'm not sure what it is for APFS, I'd guess 4KiB. It could actually be inefficient depending on the use case, e.g. a 1MiB file with a single byte change in the middle, if it were a single 1MiB extent, becomes three extents with COW:
0-500KiB - extent 1
500-504KiB - hole where stale data is
504KiB-1MiB - extent 3
4KiB - extent 2, with new data, a copy of 4095 bytes from the above hole, with 1 bytes of new data.
Edit 2: More detailed answer on Btrfs. The whole file system on a zram device is about 260 lines using 'btrfs inspect-internal dump-tree' command. I'll excerpt just the file extents.
1. 'dd if=/dev/zero of=/mnt/test/bunchofzeros.txt bs=M count=1' results in this:
item 7 key (257 EXTENT_DATA 0) itemoff 3409 itemsize 53
generation 7 type 1 (regular)
extent data disk byte 5283840 nr 1048576
extent data offset 0 nr 1048576 ram 1048576
extent compression 0 (none)
item 7 key (262 EXTENT_DATA 0) itemoff 3409 itemsize 53
generation 9 type 1 (regular)
extent data disk byte 7401472 nr 1052672
extent data offset 0 nr 1052672 ram 1052672
extent compression 0 (none)
3. Delete that file and create a new one with the same 'dd' command as in 1.
item 7 key (266 EXTENT_DATA 0) itemoff 3409 itemsize 53
generation 11 type 1 (regular)
extent data disk byte 5283840 nr 1048576
extent data offset 0 nr 1048576 ram 1048576
extent compression 0 (none)
[root@flap ~]# dd conv=notrunc if=/dev/urandom bs=1 seek=524290 count=1 of=/mnt/test/bunchofzeros.txt
[root@flap ~]# hexdump -C /mnt/test/bunchofzeros.txt | more
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00080000 00 00 5d 00 00 00 00 00 00 00 00 00 00 00 00 00 |..].............|
00080010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00100000
item 7 key (266 EXTENT_DATA 0) itemoff 3409 itemsize 53
generation 11 type 1 (regular)
extent data disk byte 5283840 nr 1048576
extent data offset 0 nr 524288 ram 1048576
extent compression 0 (none)
item 8 key (266 EXTENT_DATA 524288) itemoff 3356 itemsize 53
generation 14 type 1 (regular)
extent data disk byte 5242880 nr 4096
extent data offset 0 nr 4096 ram 4096
extent compression 0 (none)
item 9 key (266 EXTENT_DATA 528384) itemoff 3303 itemsize 53
generation 11 type 1 (regular)
extent data disk byte 5283840 nr 1048576
extent data offset 528384 nr 520192 ram 1048576
extent compression 0 (none)
(If my opinion holds true, then deduplicating is a problem when it comes to storage: a copy made to prevent bitrot/other damage to the original data doesn't work as such.)
I'm not sure if I agree.
In an ideal world, it makes sense that performance should be paramount. In reality, I think it's often more important that computers do what we expect them to, so we can predict when they'll break and know how to resolve the problem when they do. This is all the more important in consumer software.
"My hard drive is out of space" is a very basic computer problem that most users will run into at some point. The intuitive solution is to delete stuff. If that solution doesn't work, it could be a major problem.
Besides, block-level dedup is expensive to maintain. Unless you're expecting to find a lot of duplicates -- which probably isn't the case on most end-user devices -- it's a net loss.
That’s expensive in my opinion.
OWC has made drives that fit Apple’s form factor (assuming your laptop is old enough) for a nice premium. Depending on which laptop you have, this can still be a science experiment.
Even if most files on a typical personal computer are already inherently compressed (JPEG photos, lossy audio, etc.), you're not losing any performance, and are gaining some extra space where possible.
I'm generally more worried about an SSD falling over entirely - so focus is on duplication (raid with hot spare -> offsite S3 backup).
For anyone who has ever heard of checksums this makes APFS a no-go of course.
What about ext4? Oh wait - no file data checksums - so a "no go".
Actually, it turns out plenty of folks have built plenty of storage on these platforms - including APFS.
In particular, for APFS, apple uses ECC for all hardware, uses fletcher checksums for metadata and I believe does a copy on write approach to help handle sudden power loss events etc. It seems to be working out OK for them given the prices they charge.
Also, we are left to wonder if their "reliable" SSDs are as reliable as checksums at the filesystem layer (or as reliable as both). I suspect the answer is yes, for the majority of applications running atop APFS (which is to say, iOS). Probably not for video assets on that Promise MPX bay (i.e. "external" non-Apple storage media).
At least optional checksums should be supported, then watchOS does not waste time with it but a user with 10k+ mac workstation who might still uses spinning rust for bulk data storage is SOL.
That's.. an extremely confusing way to put it. ReFS and btrfs are from-scratch new FSes.
Is NTFS+ the default on Windows 10 / Windows Server 2016 or 2019?
APFS is shipping today in quantity / as default and I believe they back migrated literally millions of devices to it something like a year ago.
I don't understand the user use case with a 10K workstation and no raid (ie, with parity etc) + SSD with internal error correction. So this is a $10K workstation with magnetic disks and no other error correcting option / layer? Why do this?
Not to mention all the ..BSD or ZfsOnLinux based storage solutions.
I am not denying that APFS is a good FS, but not even having the option of checksums given its contemporaries was clearly a political and financial decision to benefit Apple and not its users. Pointing to an opaque mix of raid (and indeed, raid10 is not even enough), super-reliable SSDs and the full stack control doesn't make the lack of checksums any better.
Apple’s hardware choices are irrelevant.
If you're going to design one now, is there any reason to not have a checksuming capability? At least as an option, even though it may be default-off.
This is one that does it with CRC32, which may or may not be sufficient for detecting bitrot. It is probably trivial to modify to support a stronger hash.
Flash controllers reserve a certain amount of blocks for CRC and check summing, so flash is much more intelligent and knowledgeable than it seems.
Assuming that the flash controller has no bugs and doesn't fetch the wrong sector/LBA.
The OS asks for LBA X, but instead Y is fetched, and the sum(Y) passes so the data is sent back as "OK". If you don't have checksums at a layer above the hardware, how do you know if the right sector was sent to you? (I've seen reports of ZFS catching errors like this.)
However, I've never seen an enterprise storage system to do a mistake like that. My archaic OCZ Vectors or Mac SSDs also didn't do something similar. The problem you mention is as sinister as bit-rot.
It's always nice that the FS is self aware about its integrity, however it may be overkill for consumer class devices and installations. Maybe making the flash controller and the storage itself more reliable should be better in the long run for these type of devices IMHO.
It's probably not needed for a vertically integrated stack of APFS on a Apple SSD controller.
It'd be nice to have fir external drives though.
I cannot find the article now, but the flash storage is way less reliable than it seems and it's correcting bit errors silently without reporting most of the time.
This article [0] shows some of the things behind the curtain in flash storage configuration and lifetime. I'd edit or add the other article if I can find it.
[0]: https://goughlui.com/2015/04/05/teardown-optimization-comsol...
RAID-5 and RAID-6 is the most primitive and probably most deployed version of this checksum based compensation and recovery methods.
Erasure/Hamming is used for bigger arrays where RAID-5/6 cannot build the disks in a reasonable amount time while they are under I/O load.
This is simply not true. First, flash is not always the place data ends at. Flash is prevalent in more points in the storage chain. Predominantly on RAID controllers' caches in last 3-5 years and hybrid drives used in laptops. So, flash-level checksumming can guarantee that the data is retrieved in the form it's written and allows neat tricks like wear-leveling and such. On the other hand data can get corrupted in other places.
e.g. Data can get corrupted in RAM, bit-rot in hard drives, RAID controllers can add a thick layer of complexity which you cannot manage or the filesystem can just make mistakes due to bugs (I've seen it all). So flash-level checksum can protect the data on the flash, but cannot guarantee that the data is correct in the first place. So if you checksummed the data and wrote it differently, FS or RAID level checksumming will catch it. This will prevent domino effects which the corrupted data can create.
Data management gets complicated fast when you need more than a few disk's aggregate capacity with high performance and reliability and, FS level checksumming is a powerful tool to ensure that.
> ...assuming you have proper control and reporting on both sides of the block device abstraction boundary.
Again this will only guarantee that the device reads the data it has written, but it won't guarantee that it had received the correct data in the first place.
> Apple's about the only one who can pull this off with their vertically integrated stack.
While Apple can do a lot of exotic stuff with the hardware, it won't be wise to create a custom flash controller and protocol to fuse FS and flash level checksums. It'll increase the software and integration cost, limit their options in hardware scene, slow down product development and plainly limit them in the long run.
I had an Intel 4 channel RAID card which corrupted the array when it wakes up from the wrong side of the bed and, it spent hours to verify and rebuild the array from the block level checksums it created on the disks during array creation. I've never lost data, but decided that it didn't worth the effort to keep the array alive and well. So, I eventually ditched it. However its activity LEDs on the board was kinda nice.
I mean, tell that to them, because that's what they've done. The T2 chip's feature set is very married to APFS. AFAIK, Linux still doesn't have working drivers for it despite it sort of looking like an NVMe drive.
Apple code has no bugs that could send back bad data? Apple has access to hardware that does not experience bit rot? Apple's gear is not susceptible to firmware hacking?
* https://www.wired.com/2015/02/nsa-firmware-hacking/
The various old school SAN vendors have all sorts of control for storage controllers and disk firmware, and I've seen ZFS checksum errors appear on scrubs with them.
'It' being checksums over data that they already know is checksummed by the F2L layer and they know the semantics of.
If you're hacking the firmware, you know that APFS is running on top of it, so you would just fix-up it's checksums too. APFS having checksums doesn't get you anything there either.
> The various old school SAN vendors have all sorts of control for storage controllers and disk firmware, and I've seen ZFS checksum errors appear on scrubs with them.
You have next to zero introspection into how those drives actually work, or where the semantics of their F2L breaks down the easiest (they hide all of that out of patent concerns). For instance do those drives work around a write ahead log primarily, or is it a more traditional block renaming tree? How many generations are there? All the BS counters in the world are next to meaningless without some base implementation knowledge that's missing.
Data can be corrupted in anywhere in this chain. Checksum or block can end up in a bad memory cell, your storage controller can bit-flip or the universe can corrupt your data on the bus. Larger storage systems also add more connections, controllers, caches and disks. So the probability increases. This is why your flash, RAID controller, transmission protocols, HDDs, RAM and everything in between have error correction capabilities in enterprise systems. However consumer systems lack some of these.
Also, not all data ends up in a cutting edge SSD. HDDs are still present and being produced. While HDDs also have some block level error correction, they are susceptible to bit rot.
At the end of the day, FS level checksumming is desirable but, it costs space and computation. Instead of reducing the runtime and performance of the computer, consumer devices rely on the recovery mechanisms of the hardware and prevent most of the problems most of the times with good-enough resiliency and reliability.
Of course, but most of this kind of corruption is trivial to recover from with just retries, that's why checksumming there works, but not on the filesystem level, where it can only detect corruption. What makes a bit more sense is something like erasure coding. Filesystem with erasure coding would probably be useful for all the broken FTLs on SD cards, eMMCs, SSDs, but at the end of the day wouldn't provide any significant level of resilience for a single disk to be worth the effort and the overhead. And checksumming alone still won't be useful.
Retries won't help you when the data was corrupted on its way to be stored.
Why not? This is exactly how such corruption is traditionally fixed. On crc error data is rejected before it is stored and retry then fixes the problem. And it's not that big of a deal either, only applications can get data checksummed in the earliest possible moment anyway. The hard part is automatically recovering from data loss and corruption later, which also makes it even unnecessary to verify if data is stored without corruption.
> Why not?
1. Data is fine in memory
2. Data is fine over PCIe.
3. Data is corrupted by firmware bug in storage controller.
4. Data (now corrupted) is sent to disk, which generates checksums for each LBA, and sends the bits to the storage medium.
5. Some time later the data is requested, disk reads bits from sectors, checksums pass, corrupted data is sent back up the stack to the application.
This is not a fantasy scenario:
* http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
* https://storagemojo.com/2007/09/19/cerns-data-corruption-res...
No, I am not. The point is: checksums allow you to know that data corruption happened in the first place. Knowing this, you can then make informed decisions.
What saves you from "data corruption and data loss" is backups. But how do you know you have to go to backups if you're not aware that your data has problems?
> They are unnecessary without automatic recovery mechanisms and even make things worse.
Checksums allow you do know that there is a problem in the first place. If you don't know there's a problem, how can you invoke "recovery mechanisms", automatic or otherwise?
If you use (say) ZFS with some level of RAID-Z over multiple disks, then you get an "automatic recover mechanism". But even for a single-disk situation, it would be handy (for me at least), to know a file is bad so I can restore it from (say) my Time Machine backup.
But I have to know that the file is corrupted in the first place. And checksums would give me that.
It doesn't actually. It introduces inconsistencies unless on first detected corruption your filesystem stops all reads and writes until you recover corrupted block from backup and you might not even have it in backup, because backup is not synchronous replication.
> Checksums allow you do know that there is a problem in the first place. If you don't know there's a problem, how can you invoke "recovery mechanisms", automatic or otherwise?
You do your own appropriate checksumming suitable for recovery mechanism that you have. It's hardly as primitive as you think, because you have to respond fast, without corruption, transparently on request, you also have to schedule a check whether you actually need to heal anything, maybe it was a transient error, then mark it as corrupted, find what to resync from where, all of which also has to be fast, which means a bit complicated algorithms with sort of checksum databases on each replica, etc.
I, as a sysadmin, have been helped by (ZFS) checksums multiple times. This includes times where I had to go to tape manually because the really expensive SAN has said "everything is fine" when it wasn't.
So telling me "checksums do not help" is contrary to my life experience.
You seem to be saying "checksums don't matter because there may be nothing we can do about about the corrupted data". So we should just blindly accept all the bits from the lower levels of the stack? We should do nothing to verify that those levels of the stack are working correctly?
You've mentioned application-level checksumming: yes, that would be good. But until every single dev adds code to checksum (and correct?) their data structures and file formats, having more checksums allows for beter information about when corruption occurs IMHO.
So why does it seem you are agruing against checksums?
FS-level checksum saves you from the situation when the underlying storage thinks everything is okay but it is not:
> This means there was a data error on the drive. But it’s worse than a typical data error — this is an error that was not detected by the hardware.
* http://changelog.complete.org/archives/9769-silent-data-corr...
* https://research.cs.wisc.edu/wind/Publications/zfs-corruptio...
* https://news.ycombinator.com/item?id=13851349 (via)
It's not an either-or situation, but rather both-and hardware- and FS-level checks.
It doesn't save you from anything, it just turns bit flips into full blocks of data loss and introduces overhead. If your application can deal with data loss it can deal with bit flips too. Filesystem-level checksumming is still useless.
> If your application can deal with data loss it can deal with bit flips too.
No, it may not. The file may mostly be okay except for a place where a single bit flip causes the value to go from positive to negative:
* https://en.wikipedia.org/wiki/Signed_number_representations
Hardware not-handling bit flips is a documented phenomenon per my citations above. It does cause issues further up the stack. FS-level checksumming gives people the option to at least detect these errors, and depending on the situation, also perhaps fix them.
It's why we have Ethernet checksums, IP checksums, TCP/UDP checksums, etc. Defense in depth.
* https://en.wikipedia.org/wiki/IPv4_header_checksum
Skipped in IPv6.
Given that I run Time Machine, yes it does: it tells me I have to restore the file from a backup.
I also use SuperDuper to create bootable clones on a rotating set of drives that I take to work for offsite backup, so the file would probably be there as well. (Though this is a bit extreme for a non-geek to do.)
Unless you're using a checksumming file system (a la ZFS), how would you know? And even if you were using ZFS, it would probably just do a re-read from another part of the mirror/RAID-Z and fix it behind the scenes.
That's the issue with people saying "things are fine": how do they actually know since we're not verifying things?
Up until fairly recently, we haven't really been looking too closely, simply trusting the lower levels of the stack:
The trash isn't magic. You delete stuff, it goes into the Trash. The Trash is represented by a ".Trashes" directory on removable media. You can delete it manually or just empty the trash.
Joe Average probably doesn't even know what a "file" is.
Finder shows a full "trash can" in the dock.
Wait, what? Even with SIP off?
Can it be disabled from within the OS? Can I add "command-to-make-system-rw" to a launchd plist that runs at load on my machine?
The default should be a restricted system, with intentional, temporary, jumps into unrestricted access for making whatever infrequent system configuration changes.
What’s the use case for constant RW access? What changes at this level so frequently?
Except that those system files are already protected behind root privileges, so they're only read-write if I have root. And, one reason the root privilege system works is because temporarily gaining root when necessary isn't painful.
I indeed don't change root files on a daily basis, but when I do, I don't want to have to go through an extended rigamarole every single time. Typing in my password should be enough.
I totally respect that Apple wants to keep normal users out of this stuff. I just want a way to remove the safety wheels one time, instead of again and again.
I suspect you can do that in a launchd script, but however much more involved it is than typing my password, I'm probably fine with leaving it as-is.
/usr/local is root:wheel by default. macOS provides it to you as a place to put your software, but it not give your user ownership of this directory.
Admin users can sudo, sudo should be used to install software. Your thinking is the shenanigans that Brew does, making `/usr/local/whatever` writable by anyone, without a password.
This is not how smart people install software.
Edit: wow what a typo. One character completely reversed the intend meaning of the last sentence.
On the contrary, I think what Homebrew does with regards to permissions is fundamentally incorrect. /usr/local, being shared, should be owned by root, and it should require administrator permissions to install software there.
Anyway, I agree, it should be root owned and use sudo/similar to install.
Sorry for the confusion!
Installing user-own software, in a user-specific location is fine.
/usr/local is not user specific, and setting the permissions so it is treated that way doesn't stop other software referring to it as a system-wide $PATH.
I guess you could put something in the ~/Library folder, although that's not ideal either...
If they didn't insist on using `/usr/local/bin` (which is in the default $PATH) the permissions issue would be much less of an issue IMO (not a non-issue, but less of an issue than it is currently)
`/usr/local/bin` is in the default $PATH, so making it world writable means anything malicious installed there may end up being called by a system utility that runs as another user than your own.
For your (and Brew's stated goal), installing into ~/bin would be a better result, because it's literally that single users account.
But the Brew developers never want to hear any criticism of their ridiculous bullshit, whether it's security issues or their half-assed dependency resolution.
On most systems with 1 user it's irrelevant as by default they are in the admin group. Rather, usr/local exists and you may read and write into it even if you don't have explicit ownership (e.g, root). Whether that's brew, or your own script doesn't really matter.
ro means no matter what I try, that file is ro unless the fs is remounted rw. Again, it doesn't negate file system level user/group permissions. and remounting a system level partition rw isn't something I'd do on a whim.
I like the idea of a ro partition for system level OS files, personally, but without user level access somehow - it's not something to be looked forward to.
Apple is clearly stating that the user will have access, so I'm not concerned on that front.
What bothers me is the "will revert to read-only after a reboot" part, which seems unnecessarily punitive. It's like Apple is saying "We're going to let you do this thing, but we don't like it, so we're going to make you redo it every single time to remind you of our disdain."
Elsewhere in this thread, Pwinnski said he likes having an extra, persistent safety check. I think that's great. But, an extra command line flag to make the setting persistent really shouldn't be too much to ask for.
If my launchd idea works in practice, this is all moot, and I retract all my complaints. I'm just nervous.
The symptoms are the system becomes almost totally unresponsive for up to 5 minutes to the point where you can't even drag and drop an existing window sometimes.
* mmap doesn't really work well on 64 bit systems * mmap will block if it has to page data in from a file * there are ten different backends to handle layering on Docker and that simple fact implies that none of them are good; if you could compose layers arbitrarily the speed and scalability of Docker would be in a different league than it is now, but you can't. So Docker is just as easily something that slows you down as speeds you up. * Filesystem metadata scans are slow, shockingly so on Windows.
I know I like developing with S3-style object stores. To some extent this can replace the traditional filesystem, in other ways it can't.
overlay2 is fast, it's in the mainline kernel, and it's now the default for new Docker installs. I expect all the devicemapper / aufs mess to be history soon.
I've been fighting to be productive on my iPad, and currently that takes the form of a remote terminal.
I've been craving the ability to run a proper Unix shell locally.
I’ve heard people speculating about “Xcode on iPad within a few years” since Swift Playgrounds was released. Hopefully it’s closer now, but I’m still skeptical.
[1] https://blink.sh
They have a lot of deep time machine integration in other parts of the system, so I suspect the staging of the projects means it is pushed off to sometime next year.
As a perverse experiment, do we know what happens if you take an APFS SSD and try to format it as a TM volume? Guessing it's still not pretty despite the fact that HDD's under APFS are PNG, but directory hardlinks are gone.
Does it work, but just fill up the disk - no deduping?