4 ms·

What jumped out to me: > Finally, at WWDC 2017, Apple announced Apple File System (APFS) for macOS (after secretly test-converting everyone’s iPhones to APFS a

What jumped out to me: > Finally, at WWDC 2017, Apple announced Apple File System (APFS) for macOS (after secretly test-converting everyone’s iPhones to APFS and then reverting them back to HFS+ as part of an earlier iOS 10.x update in one of the most audacious technological gambits in history). How can you revert a FS change like that if it goes south? You'd certainly exercise the code well but also it seems like you wouldn't be able to back out of it if something was wrong.

quux 2y ago
IIRC migrating from HFS+ to APFS can be done without touching any of the data blocks and a parallel set of APFS metadata blocks and superblocks are written to disk. In the test migrations Apple did the entire migration including generating APFS superblocks but held short of committing the change that would permanently replace the HFS+ superblocks with APFS ones. To roll back they “just” needed to clean up all the generated APFS superblocks and metadata blocks.
- MBCook 2y ago
  I think that’s what they did too. And it was a genius way of testing. They did it more than once too I think. Run the real thing, throw away the results, report all problems back to the mothership so you have a high chance of catching them all even on their multi-hundred million device fleet.
- k1t 2y ago
  Yes, that's how it's described in this talk transcript: https://asciiwwdc.com/2017/sessions/715 https://asciiwwdc.com/2017/sessions/715 Let’s say for simplification we have three metadata regions that report all the entirety of what the file system might be tracking, things like file names, time stamps, where the blocks actually live on disk, and that we also have two regions labeled file data, and if you recall during the conversion process the goal is to only replace the metadata and not touch the file data. We want that to stay exactly where it is as if nothing had happened to it. So the first thing that we’re going to do is identify exactly where the metadata is, and as we’re walking through it we’ll start writing it into the free space of the HFS+ volume. And what this gives us is crash protection and the ability to recover in the event that conversion doesn’t actually succeed. Now the metadata is identified. We’ll then start to write it out to disk, and at this point, if we were doing a dry-run conversion, we’d end here. If we’re completing the process, we will write the new superblock on top of the old one, and now we have an APFS volume.
anitil 2y ago
I watched the section from the talk [0] and there's no details given really, other than that it was done as a test of consistency. I've blown so many things up in production that I'm not sure if I could every pull the trigger on such a large migration [0] https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s
kccqzy 2y ago
You lack imagination. This is not some crown jewel only achievable by Apple. In the open source world we have tools to convert ext file systems to btrfs and (1) you could revert back; (2) you could mount the original ext file system while using the btrfs file system.
- mattgreenrocks 2y ago
  Cool!

quux 2y ago

IIRC migrating from HFS+ to APFS can be done without touching any of the data blocks and a parallel set of APFS metadata blocks and superblocks are written to disk. In the test migrations Apple did the entire migration including generating APFS superblocks but held short of committing the change that would permanently replace the HFS+ superblocks with APFS ones. To roll back they “just” needed to clean up all the generated APFS superblocks and metadata blocks.

MBCook 2y ago
I think that’s what they did too. And it was a genius way of testing. They did it more than once too I think. Run the real thing, throw away the results, report all problems back to the mothership so you have a high chance of catching them all even on their multi-hundred million device fleet.
k1t 2y ago
Yes, that's how it's described in this talk transcript: https://asciiwwdc.com/2017/sessions/715 https://asciiwwdc.com/2017/sessions/715 Let’s say for simplification we have three metadata regions that report all the entirety of what the file system might be tracking, things like file names, time stamps, where the blocks actually live on disk, and that we also have two regions labeled file data, and if you recall during the conversion process the goal is to only replace the metadata and not touch the file data. We want that to stay exactly where it is as if nothing had happened to it. So the first thing that we’re going to do is identify exactly where the metadata is, and as we’re walking through it we’ll start writing it into the free space of the HFS+ volume. And what this gives us is crash protection and the ability to recover in the event that conversion doesn’t actually succeed. Now the metadata is identified. We’ll then start to write it out to disk, and at this point, if we were doing a dry-run conversion, we’d end here. If we’re completing the process, we will write the new superblock on top of the old one, and now we have an APFS volume.

anitil 2y ago

I watched the section from the talk [0] and there's no details given really, other than that it was done as a test of consistency. I've blown so many things up in production that I'm not sure if I could every pull the trigger on such a large migration [0] https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s https://www.youtube.com/watch?v=IcyaadNy9Jk&t=1670s

kccqzy 2y ago

You lack imagination. This is not some crown jewel only achievable by Apple. In the open source world we have tools to convert ext file systems to btrfs and (1) you could revert back; (2) you could mount the original ext file system while using the btrfs file system.

mattgreenrocks 2y ago
Cool!