automatic repartitioning of devices in /etc/lvm/cache/.cache?
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?
Signature · 4 lines
http://www.subspacefield.org/~travis/ | if spammer then [email protected] "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
Quoted 3 lines · On Thu, Aug 25, 2016 at 09:20:22PM -0700…
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:
Otherwise you can search through the mailing list archives - there have been a few threads discussing similar problems.
Quoted 2 lines
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.
Quoted 2 lines · Bryn M. Reeves
Use audit, systemap, or even blktrace to constantly monitor the devices and report when something is writing to the MBR area.
Thanks!
Quoted 7 lines
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.
Quoted 6 lines
Quoted 2 lines
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?
Signature · 4 lines
http://www.subspacefield.org/~travis/ | if spammer then [email protected] "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