On Thursday, September 24, 2015, 9:15:52 AM, Phil Susi wrote: > < let's keep this on the list > Sorry... my email client defaulted to your direct email.
> On 9/23/2015 7:31 PM, Al Dunsmuir wrote: >> Keeping it visible would make it straight forward to create new tools >> such as a apple-map.fsck utility to validate the mac volume partition >> map and contained partitions. Once again, GParted would support >> calling that "check" function with little additional fuss. The map >> format is so simple (dumb == reliable), I suspect there is little real >> demand for the ability to repair a damaged map, only report any >> issues. > How would such a thing make any sense? It isn't a filesystem. You > can't have it on a non APM partitioned disk; it only has meaning in > conjunction with the partition table. Any checking of it should be done > by a partitioning tool accessing the raw disk instead of the partition. I'm not sure in which area(s) I'm not making sense. I'm not saying they don't exist 8^), merely that I'm not clear in my understanding. The map partition is not hidden on OS/X, and deciding to hide it on Linix at this point in time seems like more trouble than it is worth. I'm treating it as a filesystem that is only valid for mac volumes, and in fact is mandatory for mac volumes. It gets automatically created when the mac volume is created, and must be kept in sync with events such as creation, deletion, or movement of any other partitions on the mac volume. Sure it's not a terribly interesting filesystem. It is really just an array of 512-byte elements that describe all the active and deleted partitions on the mac volume, including itself. Swap isn't a much more complex filesystem, but libparted supports multiple type (3 Linux variants, and I believe 1 BSD). This goes along with the "swap" flag. There are a few checks that libparted currently performs when validating the Apple_parttiion_map partition. I've just incorporated those in the "apple-map" filesystem probe code. There are a very few additional checks that could be done: - verifying that all sectors on the volume are accounted for in partition entries - checking for overlapping partitions - checking that all partition types are recognized Writing a tiny utility to check this would be straight forward, but much lower in priority than other tasks. One of the utilities that claims support for mac volumes is "disktype" (from SourceForge). Upstream is present, but has not been under active development for a long time. Fedora has a version with a few patches. It had a few bugs (ran off the end of the partition list because it forgot that the map partition occupies an active partition number. I fixed that and added a bit more data output in a patch that I'd like to get into the Fedora version. >> The existing approach for other "special" partition types within >> gparted is to recognize them based on output from libparted and other >> system and filesystem-specific tools - blkid, vol_id (RIP - >> assimilated by udev (now systemd) and killed). > Speaking of that, doesn't blkid already identify the usage type of this > partition correctly and gparted could use that? blkid returns PARTLABEL="Apple". meh. lsblk (the new utility the udev developers want folks to use) recognizes it as partition type "Apple_partition_map", and label "Apple". gparted initially uses libparted to obtain partition and filesystem information. It defaults to allowing deletion/reformatting of any partition with an unknown type - OK from a brute force POV for simple partitions, but when the partition controls all the other partitions on the volume it becomes risky. It seems like many tools expect active (and important) partitions to also have a filesystem type. Maybe it's a bad assumption, but that the way they tools are currently implemented. Having libparted mark the Apple_partition_map partition with a flag called "map" gives users useful info. Recognizing a "fake" filesystem type of "apple-map" (with alias "Apple_partition_map") provides the rest. Adding a few lines of code to protect against deletion, reformatting and changing the flags was very simple. The blivet and blivet-gui packages make use of libparted (through pyparted). That's my main interest, so I wanted to use the same source of information. blivet now also uses libblkdev, so I may need to add some code (plugin?) there too. >> I have verified using gdb that my libparted changes do return the >> correct sector used/unuses geometry during the initial "apple-map" >> fileystem probe (when called by parted). I've only supported the probe >> function for now, since resizing the partition map is not terribly >> useful. I modeled this after the "linux-swap" filesystem support. > We only have the probe function these days -- all resize support was > removed in parted 3.0. It will be interesting to see how gparted is determining the used and unused sector values for a partition if they are not using the geometry returned by the probe. >> BTW, Brian has EMail from me with links to the preliminary patches on >> my web site. I can post here once I have the gparted changes complete. >> I am new to git (and GitHub), and so have getting familiar with those >> as priorities so I can fit in the preferred development process. > Indeed... it is a bit of a learning curve, but well worth it. Indeed - moving from abstract knowledge to working knowledge. Al
