[linux-lvm] Strange...

[linux-lvm] Strange...

[Ulf Bartelt]

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.

Re: [linux-lvm] Dazed & Confused

[Andreas Dilger]

Ulf Bartelt writes:
> /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

Re: [linux-lvm] Strange...

[Nils Juergens]

On Tue, 29.08.00, Ulf Bartelt <ulf@twc.de> wrote:
> (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

-- 
 >   Nils Juergens  | nils@muon.de | icq 7090774   <
 >  If we all work hard, we can turn this company  <
 >      around 360 degrees -- gruntbert(LOTD)      <

[linux-lvm] rpm

[Jan Niehusmann]

On Tue, Aug 29, 2000 at 10:22:06AM -0600, Andreas Dilger wrote:
> 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.

Re: [linux-lvm] Strange...

[Ulf Bartelt]

Hi!

Nils Juergens wrote:
> 
> On Tue, 29.08.00, Ulf Bartelt <ulf@twc.de> wrote:
> > (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.

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.

Re: [linux-lvm] Dazed & Confused

[Marcelo Tosatti]

On Tue, 29 Aug 2000, Andreas Dilger wrote:

> Ulf Bartelt writes:
> > /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.

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;
+                       }

Re: [linux-lvm] Dazed & Confused

[Andreas Dilger]

Marcelo Tosatti, writes:
> 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;
> +                       }

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

Re: [linux-lvm] Strange...

[Andreas Dilger]

Ulf Bartelt, you write:
> 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

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

[Jan Niehusmann]

On Thu, Aug 31, 2000 at 11:40:10PM -0600, Andreas Dilger wrote:
> Jan Niehusmann, you write:
> > 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

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

[Jan Niehusmann]

> - 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
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 :).

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

[Andreas Dilger]

Jan Niehusmann writes:
> 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.

> 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.

> - 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).

> - 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.

> - 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.

> - 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