On Fri, Aug 26, 2016 at 11:46:30AM +0100, Bryn M. Reeves wrote: > Use audit, systemap, or even blktrace to constantly monitor the devices and > report when something is writing to the MBR area. Thanks! > There have been several common proprietary applications that have been found > to at times cause this type of problem (proprietary RDBMS, volume and cluster > managers in particular). > > Otherwise you can search through the mailing list archives - there have > been a few threads discussing similar problems. > > > Is there any way that being listed there could be a side effect, or be > > a cause, of disk partition corruption in those devices? > > Only if some external (non-lvm2) component were reading that file and > acting on the contents. Nothing in lvm2 itself even knows how to write > a GPT partition table. Good to know. Is it possible that whatever restored a GPT (bizarrely, to the partition not the disk) also restored an LVM header and that the device ended up in the LVM cache via some automatic periodic process, or a boot-time process? Second question: What is that cache for, exactly? -- http://www.subspacefield.org/~travis/ | if spammer then john@subspacefield.org "Computer crime, the glamor crime of the 1970s, will become in the 1980s one of the greatest sources of preventable business loss." John M. Carroll, "Computer Security", first edition cover flap, 1977 _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
