LVM and sw RAID1

I am having a really difficult time being able to get LVM to recognize my /dev/md[012] arrays. The system:

(pcg@dmna) ~> uname -a
Linux dmna 2.4.0-0.21 #2 Wed Aug 23 11:46:12 EDT 2000 i686 unknown

(pcg@dmna) ~> cat /proc/lvm
LVM driver version 0.8final (15/02/2000)

Total: 0 VGs 0 PVs 0 LVs (0 LVs open)
Global: 143 bytes malloced IOP version: 6 4:01:56 active

(pcg@dmna) ~> cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid5] read_ahead 1024 sectors
md2 : active raid1 sdg1[1] sdd1[0]

        17920384 blocks [2/2] [UU]

md1 : active raid1 sdf1[1] sdc1[0]

        35840896 blocks [2/2] [UU]

md0 : active raid1 sde1[1] sdb1[0]

        17936448 blocks [2/2] [UU]

(User-space tools are 0.8final+0.8final-2 patch. /dev/sda is on a BusLogic BT-958, while sd[b-g] are on two separate channels of an Adaptec 39160.) Here is the symptom:

(pcg@dmna) ~> sudo pvcreate /dev/md0
pvcreate -- invalid partition type 0x83 for "/dev/md0" (must be 0x8e)

(pcg@dmna) ~> sudo pvcreate /dev/md1
pvcreate -- invalid partition type 0x83 for "/dev/md1" (must be 0x8e)

(pcg@dmna) ~> sudo pvcreate /dev/md2
pvcreate -- can't use DOS extended partition "/dev/md2"

Just for completeness:

(pcg@dmna) ~> sudo pvcreate -f /dev/md0
pvcreate -- invalid partition type 0x83 for "/dev/md0" (must be 0x8e)

(pcg@dmna) ~> sudo pvcreate -ff /dev/md0
pvcreate -- invalid partition type 0x83 for "/dev/md0" (must be 0x8e)

(pcg@dmna) ~> sudo pvcreate -f /dev/md1
pvcreate -- invalid partition type 0x83 for "/dev/md1" (must be 0x8e)

(pcg@dmna) ~> sudo pvcreate -ff /dev/md1
pvcreate -- invalid partition type 0x83 for "/dev/md1" (must be 0x8e)

(pcg@dmna) ~> sudo pvcreate -f /dev/md2 pvcreate -- can't use DOS extended partition "/dev/md2"

(pcg@dmna) ~> sudo pvcreate -ff /dev/md2 pvcreate -- can't use DOS extended partition "/dev/md2"

What I don't understand is how those partition types got associated with my /dev/md? devices. Some more output:

(pcg@dmna) ~> sudo lvmdiskscan
lvmdiskscan -- reading all disks / partitions (this may take a while...)
lvmdiskscan -- /dev/sda1 [ 15.66 MB] Primary LINUX native partition [0x83]
lvmdiskscan -- /dev/sda2 [ 8.53 GB] DOS extended partition [0x5]
lvmdiskscan -- /dev/sda5 [ 258.83 MB] Extended LINUX swap partition [0x82]
lvmdiskscan -- /dev/sda6 [ 8.28 GB] Extended LINUX native partition [0x83]

  lvmdiskscan -- /dev/sdb1 [      17.11 GB] Primary   [0xFD]
  lvmdiskscan -- /dev/sdc1 [      34.18 GB] Primary   [0xFD]
  lvmdiskscan -- /dev/sdd1 [      17.09 GB] Primary   [0xFD]
  lvmdiskscan -- /dev/sde1 [      17.11 GB] Primary   [0xFD]
  lvmdiskscan -- /dev/sdf1 [      34.18 GB] Primary   [0xFD]
  lvmdiskscan -- /dev/sdg1 [      17.09 GB] Primary   [0xFD]
  lvmdiskscan -- /dev/md1  [      15.66 MB] Primary  LINUX native partition [0x83]

lvmdiskscan -- /dev/md2 [ 8.53 GB] DOS extended partition [0x5]
lvmdiskscan -- 7 disks
lvmdiskscan -- 0 whole disks
lvmdiskscan -- 0 loop devices
lvmdiskscan -- 0 multiple devices
lvmdiskscan -- 0 network block devices
lvmdiskscan -- 10 partitions
lvmdiskscan -- 0 LVM physical volume partitions

As you can see, there are some pretty weird entries for /dev/md[12] and *nothing* for /dev/md0. lvmdiskscan also doesn't detect any multiple devices, which doesn't seem right. (/dev/md0 and /dev/md2 are mirrors of two 18GB disks, while /dev/md1 is a mirror of two 36GB disks.) Interestingly (and I just noticed this) the output for /dev/md1 matches that of /dev/sda1, while the output for /dev/md2 matches /dev/sda2.

Any idea of what's going on and how to fix it? Is there any other information I can provide to help?

Thanks!

/pg

Peter Green : Gospel Communications Network, SysAdmin : [email protected]
---

(Linus Torvalds' follow-up to a question about Linux)

What does /proc/partitions show you? What about cfdisk -P s /dev/sdX for each drive?

Have you tried doing this directly as root? I'm not sure if it makes a difference, but it is worth trying.

Have you applied the fixes from "BUGS" to the LVM tools?

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Thanks for the response,

also sprach adilger:

/proc/partitions:
major minor #blocks name

     8     0    8965347 sda
     8     1      16033 sda1
     8     2          1 sda2
     8     5     265041 sda5
     8     6    8683101 sda6
     8    16   17942584 sdb
     8    17   17936541 sdb1
     8    32   35843684 sdc
     8    33   35840983 sdc1
     8    48   17921835 sdd
     8    49   17920476 sdd1
     8    64   17942584 sde
     8    65   17936541 sde1
     8    80   35843684 sdf
     8    81   35840983 sdf1
     8    96   17921835 sdg
     8    97   17920476 sdg1
     9     0   17936448 md0
     9     1   35840896 md1
     9     2   17920384 md2

cfdisk:
[root@dmna /root]# cfdisk -P s /dev/sdb
Partition Table for /dev/sdb

First Last
# Type Sector Sector Offset Length Filesystem Type (ID) Flags
-- ------- -------- --------- ------ --------- ---------------------- ---------
1 Primary 0 35873144 63 35873145 Linux raid autode (FD) None (00)

It's the same for all six of the drives, except for last sector and length. The first drive is obviously different, having the root fs on it:

[root@dmna /root]# cfdisk -P s /dev/sda
Partition Table for /dev/sda

First Last
# Type Sector Sector Offset Length Filesystem Type (ID) Flags
-- ------- -------- --------- ------ --------- ---------------------- ---------

   1 Primary        0    32129      63    32130  Linux (83)             Boot (80)
   2 Primary    32130 17928539       0 17896410  Extended (05)          None (00)
   5 Logical    32130   562274      63   530145  Linux swap (82)        None (00)
   6 Logical   562275 17928539      63 17366265  Linux (83)             None (00)

Same result:

[root@dmna /root]# pvcreate /dev/md0
pvcreate -- invalid partition type 0x83 for "/dev/md0" (must be 0x8e)

[root@dmna /root]# pvcreate -f /dev/md0
pvcreate -- invalid partition type 0x83 for "/dev/md0" (must be 0x8e)

[root@dmna /root]# pvcreate -ff /dev/md0
pvcreate -- invalid partition type 0x83 for "/dev/md0" (must be 0x8e)

In the BUGS list:

* ``patch-lvm_0.8final-2 - patch against LVM 0.8final user mode tools'':
I applied this.
* ``If you compile devfs into the kernel...'': Not applicable, no devfs.
* ``Arjan Filius noted the following problem with kernel version 2.3.99-pre[23]'': Not applicable, not my kernel *plus* this was a compile problem, with which I had no difficulty.
* ``Jorg de Jong[...]detected a bug...'': I can't even get this far.
* ``in LVM 0.8e (4/1/2000) (shipped with SuSE 6.4)...'': Not my version, not my OS, not the problem I'm seeing. :)
* ``Harald Milz[...]discovered a bug with pvdisplay'': Ditto (not the problem I'm seeing).

I was pretty careful about checking everything out before-hand. That's why I'm so baffled. It seems like pvcreate shouldn't even be looking for a partition type for MD, right?

Anyway, thanks for the help thus far!

/pg

Peter Green : Gospel Communications Network, SysAdmin : [email protected]
---
Microsoft is not the answer.
Microsoft is the question.
NO (or Linux) is the answer.
(Taken from a .signature from someone from the UK, source unknown)

Have you tried running "pvcreate -v -d /dev/md0"? It may be that you get some more clues with this. Maybe even strace of the above. It looks like pvcreate is not getting the correct "dev" or "rdev" from the inode...

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

also sprach adilger:

I ran ``strace -o pv.strace -ff -s 100 -v pvcreate -d -v /dev/md0 > pv.out 2>pv.debug''. I've attached the three output files (gzip'd for pv.strace).

The problem occurs in pv_get_size() starting around line 87. The device name is looked up in the cache. If found, it is tested to be a partitioned device or not. This call returns false for the /dev/md? devices; MD_MAJOR is not listed as a valid major number for partitioned devices (rightly so, I think).

Since lvm_check_partitioned_dev() returns FALSE, the for loop is never executed, and ``i'' remains at the value to which it was initialized (0) on line 50. However, i is then used at line 103 to get the device name:

  strncpy ( disk_dev_name, dir_cache[i].dev_name, sizeof ( disk_dev_name) - 1);

This obviously assumes we're dealing solely with partitioned devices, which in my case I'm not. Since i=0, dir_cache[i].dev_name is the name of the first device: /dev/sda. The strace provides evidence of this:

write(2, "lvm_check_partitioned_dev -- LEAVING\n", 37) = 37
open("/dev/sda", O_RDONLY) = 5

Everywhere else in the strace references /dev/md0, which is what I used on the cmdline.

Do these files help any?

/pg

Peter Green : Gospel Communications Network, SysAdmin : [email protected]
---
"I don't know why, but first C programs tend to look a lot worse than
first programs in any other language (maybe except for fortran, but then
I suspect all fortran programs look like `firsts')"
(By Olaf Kirch)

pvcreate -- locking logical volume manager pvcreate -- checking physical volume name "/dev/md0" pvcreate -- getting physical volume size pvcreate -- checking partition type

<1> lvm_get_iop_version -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING
<1> lvm_get_iop_version -- AFTER ioctl ret: 0
<1> lvm_get_iop_version -- LEAVING with ret: 6
<1> lvm_lock -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING
<1> lvm_lock -- LEAVING with ret: 0
<1> pv_check_name -- CALLED eith "/dev/md0"
<22> lvm_check_chars -- CALLED with name: "/dev/md0"
<22> lvm_check_chars -- LEAVING with ret: 0
<22> lvm_check_dev -- CALLED
<22> lvm_check_dev -- LEAVING with ret: 1
<1> pv_check_name -- LEAVING with ret: 0
<1> pv_get_size -- CALLED with /dev/md0 and BFFFF76C
<22> pv_check_name -- CALLED eith "/dev/md0"
<333> lvm_check_chars -- CALLED with name: "/dev/md0" <333> lvm_check_chars -- LEAVING with ret: 0
<333> lvm_check_dev -- CALLED
<333> lvm_check_dev -- LEAVING with ret: 1
<22> pv_check_name -- LEAVING with ret: 0
<22> pv_check_part -- CALLED with /dev/md0
<333> pv_check_name -- CALLED eith "/dev/md0"
<4444> lvm_check_chars -- CALLED with name: "/dev/md0" <4444> lvm_check_chars -- LEAVING with ret: 0
<4444> lvm_check_dev -- CALLED
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> pv_check_name -- LEAVING with ret: 0
<333> lvm_dir_cache_find -- CALLED
<4444> pv_check_name -- CALLED eith "/dev/md0"
<55555> lvm_check_chars -- CALLED with name: "/dev/md0" <55555> lvm_check_chars -- LEAVING with ret: 0
<55555> lvm_check_dev -- CALLED
<55555> lvm_check_dev -- LEAVING with ret: 1
<4444> pv_check_name -- LEAVING with ret: 0
<4444> lvm_dir_cache -- CALLED
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<55555> lvm_add_dir_cache -- CALLED
<666666> lvm_check_dev -- CALLED
<666666> lvm_check_dev -- LEAVING with ret: 1
<666666> lvm_dir_cache_hit -- CALLED
<666666> lvm_dir_cache_hit -- LEAVING with ret: 0
<55555> lvm_add_dir_cache -- LEAVING
<4444> lvm_dir_cache -- LEAVING with ret: 20
<333> lvm_dir_cache_find -- LEAVING
<333> lvm_partition_count -- CALLED
<333> lvm_partition_count -- LEAVING with ret: 16
<22> pv_check_part -- LEAVING with -218
<22> lvm_dir_cache -- CALLED
<22> lvm_dir_cache -- LEAVING with ret: 20
<22> lvm_dir_cache_find -- CALLED
<333> pv_check_name -- CALLED eith "/dev/md0"
<4444> lvm_check_chars -- CALLED with name: "/dev/md0" <4444> lvm_check_chars -- LEAVING with ret: 0
<4444> lvm_check_dev -- CALLED
<4444> lvm_check_dev -- LEAVING with ret: 1
<333> pv_check_name -- LEAVING with ret: 0
<333> lvm_dir_cache -- CALLED
<333> lvm_dir_cache -- LEAVING with ret: 20
<22> lvm_dir_cache_find -- LEAVING
<22> lvm_check_partitioned_dev -- CALLED
<22> lvm_check_partitioned_dev -- LEAVING
<1> pv_get_size -- BEFORE llseek 0:0
<1> pv_get_size -- part[0].sys_ind: 83 part[0].nr_sects: 32067 <1> pv_get_size -- first == 1
<1> pv_get_size -- part_i == part_i_tmp
<1> pv_get_size -- LEAVING with ret: 32067
pvcreate -- invalid partition type 0x83 for "/dev/md0" (must be 0x8e)

<1> lvm_unlock -- CALLED
<1> lvm_unlock -- LEAVING with ret: 0

I _think_ it would be possible to replace all of this partition-reading crap with a much simpler solution - read /proc/partitions, or do BLKGETSIZE ioctl, or failing that do a binary search of the device trying to read data - code exists in mke2fs and ext2resize. The below is half of Andrea Arcangeli's Alpha code, and half code from ext2resize. Give it a try for pv_get_size.c.

I also don't see much use for lvm_check_dev(), which seems to be very high maintenance (it needs to track all new devices added to the kernel), and pv_check_name() also really relies on specific names for specific devices. Can't lvm_check_dev() simply check if we are dealing with a rw block device, and get rid of pv_check_name() entirely? Granted that some people will try to make PVs on /dev/ram0 or /dev/fd0, but maybe they should be allowed to try, and maybe they have a good reason to do so (e.g. /dev/fd0 is really a 100MB zip disk or something). I suppose it shouldn't be possible to make a PV on an LV...

The only remaining difficulty lies in checking the partition type. This could be done by a shell command out to fdisk or cfdisk, or by simply trusting the user to do the right thing. None of the other tools like mke2fs check if the partition type is correct - they simply go ahead and do what you ask. I can see checking if the partition is mounted but that's about it...

Cheers, Andreas
--- cut here ---
int valid_off(int fd, __loff_t offset)

{
	char c;

	/* should probably use lseek64 if available */
	return (llseek(fd, offset, SEEK_SET) < 0 || read(fd, &c, 1) < 1)? 0 : 1;  
}

unsigned long pv_get_size(char *dev_name, struct partition *dummy)

{
	loff_t low, high;
	int pv_fd;
	unsigned long size;

	pv_fd = open(dev_name, O_RDONLY);
	if (pv_fd < 0)
		return -LVM_EPV_GET_SIZE_OPEN;

	if (ioctl(pv_fd, BLKGETSIZE, &size) < 0) {
		for (low = 0, high = 1024; valid_off(pv_fd, high); high *= 2)
			low = high;

		while (low < high - 1) {
			loff_t mid = (low + high) / 2;

			if (valid_off(pv_fd, mid))
				low = mid;
			else
				high = mid;
		}

		size = high >> 9;
	}
	close(pv_fd);
	return size;
}

--- cut here ---

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

I'm a bit confused. Shouldnt the kernel-version be something like "2.4.0-testN" instead of "2.4.0-0.21"?

I for one am using 2.4.0-test5 with LVM 0.8final on sw-Raid Lv.5 wihout any problems so far, my pvcreate behaved like it should.

'later,

Nils

also sprach nils:

It's a RedHat kernel from rawhide.

Hrm, I might try the stock kernel instead. Usually, RedHat does fairly good things with any patches they add to their kernel, but this might be a case in which they've done something naughty.

Thanks for the pointers!

/pg

Peter Green : Gospel Communications Network, SysAdmin : [email protected]
---
/*
 * Oops. The kernel tried to access some bad page. We'll have to
 * terminate things with extreme prejudice.
*/
die_if_kernel("Oops", regs, error_code);
(From linux/arch/i386/mm/fault.c)				   

also sprach nils:

Okay, I've installed 2.4.0-test6 with the exact same results. Stock lvm tools give ``invalid partition type 0x83'' for /dev/md0, my altered tools give no errors for pvcreate, but nothing shows up in pvscan.

Could it be a LVM+RAIDn problem where n != 5?

/pg

Peter Green : Gospel Communications Network, SysAdmin : [email protected]
---
Feel free to contact me (flames about my english and the useless of this
driver will be redirected to /dev/null, oh no, it's full...).
(Michael Beck, describing the PC-speaker sound device)

good it seems you found the first bug in lvm_dir_cache

the second bug is in a function called something like pv_check_all_pv it tries to remove all block devices that are part of an md device, finds none and removes the md device.

obviously this check is not needed unless you have a raid partition of type 0x8e, or you use full disks.

good luck

L.

P.S. i noticed the result of this routines varies depending with system configuration, at one particular point pv_check_all_pv did segfault on me, i removed a disk an it did work :(

i suggest someone reviews that code.

Luca Berra -- [email protected]
    Communication Media & Services S.r.l.

I'm not sure. I just tried raid1 on my setup and was able to use pvcreate without (obvious) problems...

-----------------------------------------------------------------------

sisko:~# pvcreate -v /dev/md1
pvcreate -- locking logical volume manager
pvcreate -- checking physical volume name "/dev/md1"
pvcreate -- getting physical volume size
pvcreate -- checking partition type
pvcreate -- creating new physical volume
pvcreate -- setting up physical volume for /dev/md1 with 79746048 sectors
pvcreate -- writing physical volume data to disk "/dev/md1"
pvcreate -- physical volume "/dev/md1" successfully created
pvcreate -- unlocking logical volume manager
-----------------------------------------------------------------------

but then i find lvm reports the wrong size on that pv, it actually reports the size to be the same as on the other pv (/dev/md0)

------------------------------------------------------------------------

sisko:~# pvscan
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- ACTIVE   PV "/dev/md0" of VG "raidvolumes" [38.02 GB / 16.02 GB free]
pvscan -- inactive PV "/dev/md1"  is in no VG  [38.03 GB]
pvscan -- total: 2 [76.05 GB] / in use: 1 [38.03 GB] / in no VG: 1 [38.03 GB]
------------------------------------------------------------------------

/dev/md1 should be about 1.2 GB, not 38 GB.

I now remeber i also had troubles with vgchange which had to do with vg_check_online_all_pv(). I applied a _very_dirty_ hack to get around the problem (which i think only works because i just use raid-devices as pv's so use at own risk :)) )

-----------------------------------------------------------------------

@@ -343,7 +343,7 @@
             if ( opt_v > 0) printf ( "%s -- checking if all physical volumes "
                                      "of volume group \"%s\" are available\n",
                                      cmd, vg_name);
-            if ( ( ret = vg_check_online_all_pv ( vg, &pv_offl,
+            if ( ! ( ret = vg_check_online_all_pv ( vg, &pv_offl,
                                                   &pv_incons)) < 0) {
                if ( ret == -LVM_EPV_READ_PV_CREATE_NAME_FROM_KDEV_T) {
                      fprintf ( stderr, "%s -- ERROR: can't get name(s) of "

-----------------------------------------------------------------------

have fun,

Nils

hello you have stumbled upon a (nother) nice bug in lvm
i asked for help twice on this list, none helped even bothered to answer, anyway i found the bug, well there is more than one preventing you to use raid and LVM, fixed that and pvmoved everything onto my lvm+raid5 (fixing another bug in the process).
Well, i discovered that reiserfs + LVM + raid DOES NOT WORK, it actually filled 95% of my files with zeroes :)

(*use the tape luke*)

unluckyli the patch to fix lvm+raid was not on tape, so i will post it as soon i manage to rewrite it from memory, hold your breath and mail me personally if i forget :)

BTW i am back with ext2 and it works

Regards.
L.

Luca Berra -- [email protected]
    Communication Media & Services S.r.l.

Luca Berra write:

Can you send your fixes to the list? At least then everyone else doesn't need to fix the same bugs. It would be even better if Heinz made a new bugfix release, but I watch the list for fixes anyways...

No journalling filesystem will work properly with RAID 5 - not reiserfs and not ext3. You need to stick with a non-journalling filesystem, or use RAID1. It may be that this is supposed to be fixed in 2.4, but I'm not 100% sure...

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Andreas _please_ read my emails
i said that my fix was trashed due to fs failure, i will post it to the list as soon as i write it again.
i posted what i remembered, tomorrow i dun't have to work so i will look into it.
i also watch for fixes, i even made a nice big patch encmpassing everithing that went on the list, sadly it was on a reiserfs fs.

I probably dinna specify but it i am running 2.4.0-test7pre5 so i can confirm reiserfs not working on raid+lvm with 2.4 AFAIR the problem with journaling and raid was due to raid's usage of the buffer cache during recnstruction, there was no reconstrucion happening on my system. i will also try reiserfs on raid without lvm, i cannot try ext3 since there isn't any patch for 2.4

L.

Luca Berra -- [email protected]
    Communication Media & Services S.r.l.

If you have more information, please send a bugrapport to [email protected].

For linux 2.2 it will not work with raid5 at all, the reconstruction issue is just for mirroring....I think.

From Chris Mason on [email protected]:

Correct, any hardware raid is safe. For software, striping is ok. Mirroring is ok, but you *cannot* use the online mirror rebuild. software raid5 is unsafe. lvm is safe.

Yes, software raid in 2.4 is working properly, and so is lvm.

Ragnar Kjorstad
Torque Systems / Big Storage

also sprach pcg:

Just as a followup, with the exact same system BUT using the SuSE lvm tools (lvm-0.8-70; see rpmfind.net), everything seems to work. (The Mandrake RPM at rpmfind did *not* work.)

I would be interested in seeing what SuSE has done to the source for the tools. I'm sure the developers here ought to be as well. :)

Anyway, thanks for all the help. Anyone who is running into similar problems might consider fetching the RPM I've mentioned above; you'll be glad you did!

/pg

Peter Green : Gospel Communications Network, SysAdmin : [email protected]
---
I'd rather be rich than stupid.
 (Jack Handey)

could you please try it again with lvm-0.8final-0.2mdk.i586.rpm? It's available from http://www.hitnet.rwth-aachen.de/~jan/lvm/lvm-0.8final-0.2mdk.i586.rpm

I added some fixes to version -0.1mdk, and IIRC one of them had something to do with md scanning. (As I don't use RAID myself, it am not so sure...)

Note that it's not an official mandrake rpm.

The source is here:
http://www.hitnet.rwth-aachen.de/~jan/lvm/lvm-0.8final-0.2mdk.src.rpm

Jan

also sprach jan:

Not really; this system is too close to live to monkey around with it. If I'm building another machine before too long, I'll try it. Otherwise, I'm afraid I can't help.

/pg

Peter Green : Gospel Communications Network, SysAdmin : [email protected]
---
Linux is obsolete
(Andrew Tanenbaum)