LVM writes on raw disk of ATA RAID Mirror

It would be nice if it were possible to do this. Is this perhaps the CONFIG_PDC202XX_FORCE flag (turned off, or on)?

The Linux kernel configure help for it isn't very enlightening. And as best I can tell it affects only the flags passed to some of the Promise cards during setup. But interestingly _not_ the PDC20271 which is on the Promise TX2000 card I have. (Or the PDC20268, PDC20269, PDC20275, or PDC20277. It does affect the PDC20270 and PDC20276 though, and most of the older PDC chipsets (in pdc202xx_old.h).)

Ewen

According to this message:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=20030405112008%2462da%40gated-at.bofh.it

from Andre Hedrick (Linux IDE maintainer), the CONFIG_PDC202XX_FORCE option is intended to force recognition of the Promise card's IDE channels as IDE devices, in order to be able to use the Linux pdcraid (ATA-RAID) driver. (They are apparently semi-disabled in the PCI configuration data, by default, so that only the Promise SCSI device driver can find them.) It should be on for using the pdcraid/ata-raid support, and off if you are using the Promise "SCSI" device driver. (And as I noted earlier, only certain chipsets seem to actually use this option; the rest just default to forced on.)

This tends to confirm my view that if you use the ataraid driver, then you'll see both the raw /dev/hd* devices, and also the /dev/ataraid/d0* devices, since the ataraid/pdcraid driver appears to search the /dev/hd* IDE controllers for likely devices based on partition signatures.

Which means that LVM needs to deal with the aliasing effects in some manner, either by recognising the ataraid devices first and ignoring the underlying devices, or by very loudly refusing to work with ataraid at all.

Ewen

vgscan has similar problems with MD devices in a software RAID10 (but not RAID1) configuration.

In software RAID10 one creates a number of software RAID1 devices and then stripes across those with RAID0. For example if you have a 4 disk RAID10 setup you would have /dev/md0 and /dev/md1 as RAID1 devices and then /dev/md2 would be a stripe across /dev/md[0,1]

The problem occurs when vgcreate adds the LVM metadata to the device. When you run 'vgcreate somename0 /dev/md2' it adds the metadata to /dev/md2, but since /dev/md0 is the first device in the RAID10 array, the metadata is in the exact same location on /dev/md0 and /dev/md2. Upon reboot (or a subsequent vgscan), LVM complains that it can't find all of the PE's on the volume group created because it's reading the information from md0 instead of md2

I was trying to hack vgscan to get my setup working but I needed the box working ASAP so time dictated that I use the KludgeMethod(tm). Someone on the list recommended that I move /dev/md0 before I run my vgscan. That worked in my case and I hacked my sysint script to move md0, run vgscan, and then move it back. Not elegant AT ALL, but it works.

I'm not sure if a similar quick fix could work for you or not. You would have to make sure that the ataraid driver "built" the /dev/ataraid* entries, then move /dev/hd* somewhere, run vgscan, and then move them back.

Make sure you test first and have a backup (do people still do those? :) ) before trying anything.

HTH,
Andy.