[linux-lvm] automatic repartitioning of devices in /etc/lvm/cache/.cache?

[linux-lvm] automatic repartitioning of devices in /etc/lvm/cache/.cache?

[travis+ml-linux-lvm]

Hello, I've got a persistent problem in that the second two disks of my array
occasionally have their heads wiped, with a GPT showing up at the beginning
of the partition, with the same partitioning structure as the main disk GPT.

The overall structure is:

md127 = /dev/sd{b,c,d,e}1
LUKS on that
PV/VG/LV on that.

So my ONLY lead so far, that distinguishes sd{d,e}1 (which get wiped)
from sd{b,c}1 is that they were listed in /etc/lvm/cache/.cache.

Is there any way that being listed there could be a side effect, or be
a cause, of disk partition corruption in those devices?

This system crashed and failed to recover, but I strongly suspect that
it was unattended and un-administered between the last boot and an
unrelated kernel panic, whereupon I discovered the disk corruption.

So, I'm wondering, is there any unattended process, or possibly any one
triggered by an admin, that would re-partition a device listed there,
or restore a GPT from backup or something?
-- 
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

Re: [linux-lvm] automatic repartitioning of devices in /etc/lvm/cache/.cache?

[Bryn M. Reeves]

On Thu, Aug 25, 2016 at 09:20:22PM -0700, travis+ml-linux-lvm@subspacefield.org wrote:
> Hello, I've got a persistent problem in that the second two disks of my array
> occasionally have their heads wiped, with a GPT showing up at the beginning
> of the partition, with the same partitioning structure as the main disk GPT.

Use audit, systemap, or even blktrace to constantly monitor the devices and
report when something is writing to the MBR area.

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).

If you have a Red Hat subscription you may find relevant knowledge base
articles in the portal:

  https://access.redhat.com/

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.

Regards,
Bryn.
 

Re: [linux-lvm] automatic repartitioning of devices in /etc/lvm/cache/.cache?

[travis+ml-linux-lvm]

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