@ilovezfs Regardless of the labeling information you use (MBR, GPT, GPT with
protective MBR, BSD disk label, UFS labels, ZFS labels, GELI encryption labels,
software RAID metadata, etc, etc) there is a possibility for conflict. The only
way to deal with this is to prioritize the order in which handlers for these
formats attach. Then, when you attempt to splat one format on top of another,
the new device layout either shows up in /dev or it doesn't - e.g. the previous
label data wasn't overwritten/invalidated and has sufficient priority to
overrule the newly written label data. Resolving this confusion requires
querying the provider for the device: "Oh, this device is being provided by
GPT, so I need to kill the GPT partition first".
Mandates work for those that hear and adhere to them. But we still have to do
something sane when someone doesn't know better or makes a mistake. FreeBSD's
GEOM system for "device tasting" and partition control isn't perfect, but it
works well enough that typically the confusion @don-brady talks about either
doesn't happen or can be readily understood using the GEOM ("What's providing
this device?") and partitioning tools. Where this isn't the case, we need to
improve GEOM, how probes are prioritized, tools/tool output, and documentation
so that conflicts are easy to understand and resolve.
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/32#issuecomment-152839854_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
