Apple Did a Dry Run of APFS on Your Device Even Before iOS 10.3 (2017) | Hacker News Reader

Apple Did a Dry Run of APFS on Your Device Even Before iOS 10.3 (2017)

macobserver.com

46 pointstosh7 comments

Good.

If they're going to migrate my data to an entirely new file system, I want that tested as thoroughly as possible. This happened during the update, when you can't use the phone by definition, and was removed completely before the update finished. Who cares, it's running the middle of the night.

Well, I care. I'm glad they did it, the migration went off without a hitch when they shipped it, I doubt I was even aware it had happened right away.

And if they bricked your device while doing the testing on it without telling you? What if you were going on a trip the next day and you phone was out because they were quite literally testing in production? Why, that's just fine! You would go and buy another (i)phone and everything would be just fine, even better, you would have a brand new iphone! On an unrelated note, there is this bridge that just came on the market, would you be interesting in buying a share?

None of those things happened.

Instead Apple transitioned everyone's phone to a new and better filesystem, without a hitch.

If it had been bad, it would be. But it wasn't, so it's not.

It's just the mental acceptance of them having the audacity (and ability) to test a filesystem transition without the owners explicit consent.

I would not be happy about it anyway, and hearing that they did it makes me even more sure about not entering the Apple ecosystem.

> "we were trial migrating your whole file system … consistency checking it … reporting back to us whether the upgrade was 100 percent clean, then rolling it back"

Actually doing the migration then undoing it is very much not a dry run. I assume they included an "if anything goes wrong, restore everything from iCloud" check or something, because otherwise an unexpected flaw in migration/rollback could mean data loss.

One key feature of APFS was the metadata location didn't overlap with any hfs+ metadata location, so the two file systems could co-exist on the drive. So I presume they created the apfs metadata inside the hfs+ unallocated space, and so if it failed, hfs+ would happily overwrite the apfs metadata and continue on without any impact.

From the linked article:

«Namely, in iOS 10.1 and 102 (sic!), metadata for APFS was test written and the superblock header was created but not actually written out. The file data remained untouched for safety and crash protection and the user remained in HFS+.»

Reply on news.ycombinator.com