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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
