Re: still a problem with gpt(8) reading from LVM volumes? (was: problems with GPT (and maybe dkctl wedges) on LVM volumes)

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Mar 19,  6:02, Michael van Elst wrote:
} woods%planix.ca@localhost ("Greg A. Woods") writes:
} >At Fri, 12 Mar 2021 14:02:06 -0800, I wrote:
} >>
} >> # gpt -vvv show -a /dev/mapper/rvg0-nbtest.0
} >> /dev/mapper/rvg0-nbtest.0: mediasize=41943040; sectorsize=512; blocks=81920
} >> /dev/mapper/rvg0-nbtest.0: PMBR at sector 0
} >> /dev/mapper/rvg0-nbtest.0: Pri GPT at sector 1
} >> /dev/mapper/rvg0-nbtest.0: GPT partition: type=ffs, start=64, size=41942943
} >> gpt: /dev/mapper/rvg0-nbtest.0: map entry doesn't fit media: new start + new size < start + size
} >> (22 + 13fde < 40 + 27fff9f)
} 
} >I'm still not quite sure why gpt(8) can't show me the full partition
} >table when reading from a raw LVM volume (dm) device as above in exactly
} >the same way it does when reading from the raw (xbd emulated) disk in
} >the domU.
} 
} gpt sees that the medium has only 41MByte and the partition exceeds that
} and bails out.

     gpt(8) is basically an exercise in linked list manipulation
where each node represents a partition.  It looks like a first year
compsci exercise where the assignment was to find a practical use
for a linked list.  Partitions must be monotonically increasing
with no overlap and fit on the disk.  This means that it is extremely
inflexible and can not handle any form of corruption, which means
that it can not be used to fix said corruption.

     One of the projects I have in mind is to replace the data
structure.  One good thing about the program is that all manipulation
of the data structure is done through access routines and is
appropriately contained in map.c and map.h.  One thing that is
slowing me down is thinking of an appropriate data structure for
tracking allocated space (the current method gets this pretty much
for free).  One tradional way to do this would be to use a bitmap,
but with the size of modern disks, that is completely infeasible.
Note that whatever method is chosen must be able to handle duplicate
allocations (i.e. overlapping partitions).

}-- End of excerpt from Michael van Elst