2.4.20-pre4 + LVM = hosed /proc/partitions

Try compiling CONFIG_BLK_DEV_LVM into 2.4.20-pre4 and then run 'cat /proc/partitions' for some amusement. I really like the way it prints /dev/lvmX, where X is first a-z, and then proceeds to apparently increment X another 229 times...

    $ cat /proc/partitions | wc -l
      259

And /proc/partitions now contains only LVM entries...

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

It also seems to occur for md and ataraid.

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

You should consider switching to LVM2. LVM2 doesn't have such problem, and it seems more stable too.

Jeff

I'm not actually using it. Just compiled it in and saw wierd stuff happening...

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Fixed in -ac for a while - not had time to do another sync with Marcelo though

Sigh. I wished I'd known an hour ago, since it would have saved me the bother of figuring it out myself.

Marcello,
Please apply the following patch to 2.4.20-pre5. The patch that went into -pre2 had a nasty bug in it that causes /proc/partitions to behave very badly. This patch restores it to sanity.

@@ -194,9 +194,7 @@
 
 	/* show the full disk and all non-0 size partitions of it */
 	for (n = 0; n < (gp->nr_real << gp->minor_shift); n++) {
-		int mask = (1<<gp->minor_shift) - 1;
-
-		if (!(n & mask) || gp->part[n].nr_sects) {
+		if (gp->part[n].nr_sects) {
 #ifdef CONFIG_BLK_STATS
 			struct hd_struct *hd = &gp->part[n];
 

-Erik

--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--