[Parted-maintainers] Bug#778712: libparted2: Breakage of RAID GPT header

[jnqnfe]

On Fri, 2015-02-20 at 15:59 -0500, Phillip Susi wrote:
> It also shows no GPT either, because it is still seeing the stale
> cached data where there is nothing on the drive but zeros.

Sure, yes.

The fdisk4 output does show GPT info for the RAID device (md126) it just
modified, so it is presumably flushing info for only that RAID device
upon writing the change (or simply combining the new info it has with
the already retrieved cache data), and not bothering to flush anything
else.

Since the execution of 'fdisk -l' after using fdisk to create the GPT
tables does not seem to have flushed the cache of the array members, I
would conclude that fdisk does not automatically flush the caches when
it feels there may be no point, and thus per your description of
parted's behavior, parted must indeed have been responsible for flushing
the cache and allowing fdisk to then gain a fresh view of things upon
the second run of it.

It may be fair to say that in many/most cases there indeed would be no
point in fdisk just flushing this info for every disk; even here it
would not actually be a problem if only it recognised these disks as
members of a RAID array and thus completely ignored them as far as
reading partition tables goes.

> Right... fdisk flushes the cache on /dev/md127, but not /dev/sdb,
> since it isn't operating on /dev/sdb.  When you run parted -l, it
> walks every disk in the system and as part of reading from each one,
> flushes the cache, thus, /dev/sdb has its cache flushed, and reads the
> new partition table from the disk.

Yeah. I previously had no idea that caching would be involved here.

Going back over those fdisk outputs I do notice now that for sdb it is
outputting "Disklabel type: dos" when the cache has been flushed.

Again, thanks for the help, and patience.