site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -Kevin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Jan 19, 2009, at 9:48 AM, Stephen Hoffman wrote: The whole recovery design seems odd. If the primary GPT (the blocks after the MBR) are stomped on, what are the chance that the rest of the volume structures are valid; that the rest of the core volume structures within the partition(s) haven't also been stomped on? Depends on what's eating your data. If your threat model is "somebody doing random writes", the back of the disk is pretty much as good as anyone else. If your thread model is "someone doing contiguous data transfers to the wrong place", the back is an excellent choice- it's as far away from the front as possible, thus it has the best chance of survival.
(And what happens when you have three GPT structures during a transition - the front GPT, old back GPT, new back GPT - what happens when you get rolling with an expansion and fail; which GPT do you believe, and >how do you clean up?) If your expanding the disk, the old back GPT is irrelevant. Once you write the new front GPT, you won't be able to find the old back GPT, since you won't know where the old disk boundary is. And if you're going to do a backup of a critical structure, why at the back of the disk and not at a known block-offset pattern (look for a backup every 1001 blocks into the disk, for instance) within the disk?
Sounds like a great idea, except that no existing current or legacy file system supports it. If your writing the spec for a partition scheme you have to operate within the constraints that filesystems impose. That basically means that the front of the disk and the back of the disk are the only known locations you can shove data. This email sent to site_archiver@lists.apple.com