Strange...

linux-lvm Ulf Bartelt 5 participants 11 messages Aug 29, 2000 – Sep 1, 2000 1 message not in the archive

lore

Share & tools

lore

Ulf Bartelt

author

2000-08-29 07:18 UTC #0 lore raw

Hi!

I just wanted to resize /home/ftp...

Here is what happened:

(root@kira:/0)~# mount
/dev/hda2 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext2 (rw,errors=remount-ro)
/dev/vgkira/tmp on /tmp type ext2 (rw,errors=remount-ro)
/dev/vgkira/usr on /usr type ext2 (rw,errors=remount-ro)
/dev/vgkira/var on /var type ext2 (rw,errors=remount-ro)
/dev/vgkira/opt on /opt type ext2 (rw,errors=remount-ro)
/dev/vgkira/home on /home type ext2 (rw,errors=remount-ro)
/dev/vgkira/ftp on /home/ftp type ext2 (ro,errors=remount-ro)
/dev/vgkira/install on /home/ftp/install type ext2
(rw,errors=remount-ro)
/dev/vgkira/ftp2 on /home/ftp2 type ext2 (rw,errors=remount-ro)
/dev/vgkira/sys on /sys type ext2 (rw,errors=remount-ro)
(root@kira:/0)~# umount /home/ftp/install/
(root@kira:/0)~# umount /home/ftp
(root@kira:/0)~# e2fsadm -L+1G /dev/vgkira/ftp
e2fsadm -- ERROR: "/dev/vgkira/ftp" is mounted on "/home/ftp2"
e2fsadm -- please umount it to resize

(root@kira:/0)~# mount
/dev/hda2 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type ext2 (rw,errors=remount-ro)
/dev/vgkira/tmp on /tmp type ext2 (rw,errors=remount-ro)
/dev/vgkira/usr on /usr type ext2 (rw,errors=remount-ro)
/dev/vgkira/var on /var type ext2 (rw,errors=remount-ro)
/dev/vgkira/opt on /opt type ext2 (rw,errors=remount-ro)
/dev/vgkira/home on /home type ext2 (rw,errors=remount-ro)
/dev/vgkira/ftp2 on /home/ftp2 type ext2 (rw,errors=remount-ro)
/dev/vgkira/sys on /sys type ext2 (rw,errors=remount-ro)
(root@kira:/0)~#

This happened using lvm-0.7 on a 2.2.13 kernel...

Since the last successfull resize operations, I merged 2 VGs. Formerly my LVs were spread accross 2 PVs, one per harddisk...

...I see this behaviour for the first time now... ...I retried it after a reboot, but the effect is the same...

...or is it too early in the morning and Iï¿½d better get some cups of coffee??? ;-)

Bye for now...

Ulf.

Andreas Dilger

2000-08-29 16:22 UTC #1 lore raw

Re: [linux-lvm] Dazed & Confused

Quoted 6 lines · Ulf Bartelt

/dev/vgkira/ftp on /home/ftp type ext2 (ro,errors=remount-ro) /dev/vgkira/ftp2 on /home/ftp2 type ext2 (rw,errors=remount-ro)
(root@kira:/0)~# e2fsadm -L+1G /dev/vgkira/ftp
e2fsadm -- ERROR: "/dev/vgkira/ftp" is mounted on "/home/ftp2"
e2fsadm -- please umount it to resize

This is a bug in how e2fsadm checks to see if a filesystem is mounted. I have fixed this in my version of e2fsadm, as well as adding support for ext2resize and ext2online, so you don't even need to unmount the filesystem to resize it (if you have the ext2online kernel patch).

See ftp.lustre.org:/pub/adilger for an SRPM which has a patch to fix all known LVM user-tools bugs, as well as a kernel patch for 0.8final on 2.2.16. I was told by Les Hazelton that my LVM kernel patch will apply cleanly to kernel-source-2.2.17-0.16mdk.i586.rpm, from the mandrake cooker section on rpmfind.net.

Cheers, Andreas

Nils Juergens

2000-08-29 17:58 UTC #9 lore raw

In reply to Ulf Bartelt

Quoted 6 lines · Ulf Bartelt

(root@kira:/0)~# umount /home/ftp/install/
(root@kira:/0)~# umount /home/ftp
(root@kira:/0)~# e2fsadm -L+1G /dev/vgkira/ftp
e2fsadm -- ERROR: "/dev/vgkira/ftp" is mounted on "/home/ftp2"
e2fsadm -- please umount it to resize

Have you tried using "lvextend" by hand? That should work.

In that case you might try ext2resize instead of resize2fs. You don't even need to supply the exact size of the LV to ext2resize. "ext2resize <devicename>" will automagically extend the filesystem to the size of the LV.

cu,

Nils

Quoted 3 lines

  Nils Juergens  | [email protected] | icq 7090774   <
 If we all work hard, we can turn this company  <
     around 360 degrees -- gruntbert(LOTD)      <

Jan Niehusmann

2000-08-29 18:32 UTC #2 lore raw

[linux-lvm] rpm

In reply to Andreas Dilger

Quoted 5 lines · Andreas Dilger

See ftp.lustre.org:/pub/adilger for an SRPM which has a patch to fix all known LVM user-tools bugs, as well as a kernel patch for 0.8final on 2.2.16. I was told by Les Hazelton that my LVM kernel patch will apply cleanly to kernel-source-2.2.17-0.16mdk.i586.rpm, from the mandrake cooker section on rpmfind.net.

I compared your .srpm with the one I created for mandrake. There where only minor differences(*), but I noticed you removed dependence on the local lvm.h, while I don't use linux/lvm.h any more.

I think it's better not to use linux/lvm.h because kernel headers may belong to an older kernel version without lvm support. (Linus said on linux-kernel that he prefers that /usr/include/linux and /usr/src/linux are of the kernel version used when glibc was compiled)

On mandrake, the standard kernel doesn't support lvm, but on 7.2 it will probably be possible to install a 2.4 kernel optionally. linux/lvm.h will not be available at build time.

What do you think?

Jan

(*) I did miss some minor bugfixes, and I'll upload an updated SRPM, soon.

Ulf Bartelt

author

2000-08-30 07:08 UTC #10 lore raw

In reply to Nils Juergens

Hi!

Quoted 8 lines · Nils Juergens

Quoted 5 lines · Ulf Bartelt

(root@kira:/0)~# umount /home/ftp/install/
(root@kira:/0)~# umount /home/ftp
(root@kira:/0)~# e2fsadm -L+1G /dev/vgkira/ftp
e2fsadm -- ERROR: "/dev/vgkira/ftp" is mounted on "/home/ftp2"
e2fsadm -- please umount it to resize

Quoted 6 lines

Have you tried using "lvextend" by hand? That should work.
In that case you might try ext2resize instead of resize2fs. You don't even need to supply the exact size of the LV to ext2resize. "ext2resize <devicename>" will automagically extend the filesystem to the size of the LV.

Neither mount nor /proc/mounts claimed the LV to be mounted.

I tried and solved the problem this way:

rename the LV /dev/vgkira/ftp to /dev/vgkira/ptf (necessary lvchange commands not mentioned)

run e2fsadm on the renamed LV

rename th LV back

use the LV as usual

I had no time to look in the sources but I for now I guess e2fsadm fails if used on a LV with a name that is the beginning of a LV name that still is in use...

This was the case having LV names ftp and ftp2...

Bye!
Ulf.

Marcelo Tosatti

2000-08-31 18:15 UTC #7 lore raw

Re: [linux-lvm] Dazed & Confused

In reply to Andreas Dilger

Quoted 13 lines · Andreas Dilger

Quoted 6 lines · Ulf Bartelt
/dev/vgkira/ftp on /home/ftp type ext2 (ro,errors=remount-ro) /dev/vgkira/ftp2 on /home/ftp2 type ext2 (rw,errors=remount-ro)
(root@kira:/0)~# e2fsadm -L+1G /dev/vgkira/ftp
e2fsadm -- ERROR: "/dev/vgkira/ftp" is mounted on "/home/ftp2"
e2fsadm -- please umount it to resize
This is a bug in how e2fsadm checks to see if a filesystem is mounted. I have fixed this in my version of e2fsadm, as well as adding support for ext2resize and ext2online, so you don't even need to unmount the filesystem to resize it (if you have the ext2online kernel patch).

Quoted 5 lines

See ftp.lustre.org:/pub/adilger for an SRPM which has a patch to fix all known LVM user-tools bugs, as well as a kernel patch for 0.8final on 2.2.16. I was told by Les Hazelton that my LVM kernel patch will apply cleanly to kernel-source-2.2.17-0.16mdk.i586.rpm, from the mandrake cooker section on rpmfind.net.

While looking at your patch I found something which seems to be wrong.

The function lvm_snapshot_COW returns 1 on success. lvm_map() returns lvm_snapshot_COW() return code. ll_rw_block calls lvm_map_ptr() (which is lvm_map()) and expects 0 on success:

+ if ((lvm_map_ptr) (bh[i], rw) != 0) {
+ printk(KERN_ERR
+ "Bad lvm_map in ll_rw_block\n");
+ goto sorry;
+ }

Andreas Dilger

2000-09-01 08:01 UTC #8 lore raw

Re: [linux-lvm] Dazed & Confused

Review

Quoted 11 lines · Marcelo Tosatti,

While looking at your patch I found something which seems to be wrong.
The function lvm_snapshot_COW returns 1 on success. lvm_map() returns lvm_snapshot_COW() return code. ll_rw_block calls lvm_map_ptr() (which is lvm_map()) and expects 0 on success:
(quoted diff) +5 -0
+                       if ((lvm_map_ptr) (bh[i], rw) != 0) {
+                               printk(KERN_ERR
+                                      "Bad lvm_map in ll_rw_block\n");
+                               goto sorry;
+                       }

You are correct. I think that I had changed lvm-snap.c at one time so that lvm_snapshot_COW() returned 0 on success like normal kernel functions, but those changes were lost. Just change the "return 1" to "return 0" on line 290 of lvm-snap.c.

Note however, that this is exactly opposite of what is done in 2.4 code.

Cheers, Andreas

Andreas Dilger

2000-09-01 08:25 UTC #11 lore raw

In reply to Ulf Bartelt

Ulf Bartelt, you write:

Quoted 5 lines

I had no time to look in the sources but I for now I guess e2fsadm fails if used on a LV with a name that is the beginning of a LV name that still is in use...
This was the case having LV names ftp and ftp2...

Correct - it was doing strncmp() using the length of the LV name, so it was broken in a case like yours. I fixed this and a few other issues.

Cheers, Andreas

Jan Niehusmann

2000-09-01 11:29 UTC #4 lore raw

[linux-lvm] lvm.h kernel/userspace differences

In reply to a message not in the archive

Quoted 9 lines · Andreas Dilger

Jan Niehusmann, you write:
Quoted 4 lines
I think it's better not to use linux/lvm.h because kernel headers may belong to an older kernel version without lvm support. (Linus said on linux-kernel that he prefers that /usr/include/linux and /usr/src/linux are of the kernel version used when glibc was compiled)
There was always something that confused me, and I never got a response back from Heinz - in the 0.8final user tools/lib/lvm.h it says the IOP version is 7, but the 2.4 kernel lvm.h has IOP version 6 right now, so it shouldn't work, but I think the wrong header is being used...

I just compared lvm.h from 0.8final and from linux 2.4.0-test7 (which is running on this computer). You are right, IOP version is different.

But: Kernel defines LVM_DRIVER_IOP_VERSION to "6" and exports it via ioctl LVM_GET_IOP_VERSION. Userspace requests this in lvm_get_iop_version. The only place where lvm_get_iop_version gets called is LVM_CHECK_IOP in lvm_user.h, where the result (the kernel IOP version) is compared to LVM_LIB_IOP_VERSION (and not to LVM_DRIVER_IOP_VERSION), and LVM_LIB_IOP_VERSION is "6", as defined in liblvm.h.

Additionaly, the following things have changed between 0.8final lvm.h and the linux-2.4.0-test7 version:

- some includes and #ifdef KERNEL have changed, nothing that should cause binary incompatibilities, probably

- many type changes uint -> uint32_t and stuff like that. It looks like only the names have changed, not the real types, so no problem, again.

- kernel's lv_v2_t has an additional field "uint8_t __unused;" _in the middle_ of the struct. Huh. What's that?

- in the kernel, there is an lv_disk_v2_t that's missing from 0.8final. But it's identical to lv_disk_v1_t, so what's the point?

- pv_flush_req_t is missing the field "kdev_t pv_dev" in kernel. As it is shorter in kernel, and the missing field is at the end, and the struct is only copied into the kernel, this shouldn't cause problems. But things like that may become a maintenance nightmare.

- similar problem with lv_status_byname_req_t, lv_req_t and
lv_status_byindex_req_t: They are missing "ushort size" in kernel.

Jan

Jan Niehusmann

2000-09-01 11:47 UTC #5 lore raw

[linux-lvm] Re: lvm.h kernel/userspace differences

Quoted 2 lines

- kernel's lv_v2_t has an additional field "uint8_t __unused;" _in the middle_ of the struct. Huh. What's that?

Additional information:

It's been included in linux-2.3.99-pre9 or -pre10. The patch was proposed by

Quoted 5 lines · Andrea Arcangeli in a mail to linux-kernel on Apr 5. He writes:

o inserts a pad in the lv_t structure to avoid breaking the
binary tools interface. I think everybody prefers to lose 32 bit per logical volume in the system than having to change binary tools while switching between 2.2.x and 2.3.x to make snapshotting to work :).

Andreas Dilger

2000-09-01 17:53 UTC #6 lore raw

[linux-lvm] Re: lvm.h kernel/userspace differences

In reply to Jan Niehusmann

Quoted 9 lines · Jan Niehusmann

I just compared lvm.h from 0.8final and from linux 2.4.0-test7 (which is running on this computer). You are right, IOP version is different.
But: Kernel defines LVM_DRIVER_IOP_VERSION to "6" and exports it via ioctl LVM_GET_IOP_VERSION. Userspace requests this in lvm_get_iop_version. The only place where lvm_get_iop_version gets called is LVM_CHECK_IOP in lvm_user.h, where the result (the kernel IOP version) is compared to LVM_LIB_IOP_VERSION (and not to LVM_DRIVER_IOP_VERSION), and LVM_LIB_IOP_VERSION is "6", as defined in liblvm.h.

This is scary anyways.

Quoted 2 lines

Additionaly, the following things have changed between 0.8final lvm.h and the linux-2.4.0-test7 version:

This is even scarier. I _think_ that I followed the 2.4 kernel format as much as I could, so that I can use both 2.2+patch and 2.4 with the same tools.

Quoted 5 lines

- some includes and #ifdef KERNEL have changed, nothing that should cause binary incompatibilities, probably
- many type changes uint -> uint32_t and stuff like that. It looks like only the names have changed, not the real types, so no problem, again.

I know that my lvm.h works with both user and kernel (which is these changes).

Quoted 2 lines

- kernel's lv_v2_t has an additional field "uint8_t __unused;" _in the middle_ of the struct. Huh. What's that?

I don't know why the __unused field is added to the middle of the struct. This is really terrible because it has all sorts of packing issues and may cause problems if a different compiler is used for the kernel and user tools.

Quoted 2 lines

- in the kernel, there is an lv_disk_v2_t that's missing from 0.8final. But it's identical to lv_disk_v1_t, so what's the point?

Just getting rid of dead code, I guess.

Quoted 7 lines

- pv_flush_req_t is missing the field "kdev_t pv_dev" in kernel. As it is shorter in kernel, and the missing field is at the end, and the struct is only copied into the kernel, this shouldn't cause problems. But things like that may become a maintenance nightmare.
- similar problem with lv_status_byname_req_t, lv_req_t and
lv_status_byindex_req_t: They are missing "ushort size" in kernel.

I can't say I know why this was done. However, the 2.4 kernel will be the de-facto standard, so the 2.2 patch may as well work in the same way.

Cheers, Andreas