4 ms·

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 d

by 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.

by quux 2y ago

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.