RE: [linux-lvm] LVM seems to break tar and cp "stay-local" option s

RE: [linux-lvm] LVM seems to break tar and cp "stay-local" option s

[Jakma, Paul]

> Hi Paul,
> 
> what about:
> 
> cd /
> find . -print > /home/root/list
> vi list (edit to fit your wishes)
> tar -cvf- . -T /home/root/list | (cd /mynewroot; tar -xvf-)
> 
> (you might want to check the tar option for "read list from file" - it
> seems to differ between distributions)
> 

possible, and i did something similar in the end, eg  .... tar ... /bin /dev
/sbin ...

But the point is, why do these userland tools not recognise the boundary
between fs on ordinary device, and fs on lvm?

Also, another little issue, about partitioning: 

if you change the partition table with fdisk, the kernel will not update
it's in-core idea of the partition layout if any of the partitions on that
disk are in-use, eg mounted fs or swap.

However, the kernel doesn't seem to recognise partitions that are active LVM
PV's as marking that disk in use. Ie i can repartition a disk in-use by LVM,
and the kernel does not seem to know that the disk is busy and hence will
commit the new partition table to memory.

I have a feeling LVM is forgetting to set some kind of flag that marks a
physical disk device as in-use. (and this might be related to the tar/cp
"stay-local" problem aswell). However i am not a kernel hacker... :)

regards,

Paul Jakma.

RE: [linux-lvm] LVM seems to break tar and cp "stay-local" option s

[Steve_J_Brueggeman]

Well, a quick of the tar source code reveals that they're using a stat(2) and
checking
parent_device != current_stat.st_dev

to determine if the filesystem has changed.

I just did a stat(1) on some files, (using LVM 0.7), and it always returns a
minor number of 0, no matter what Logical Volume the file I checked lives on.

Then again, I got the same result on files that reside on plain SCSI partitions
(I have root and /usr on /dev/sda1 and /dev/sda3 respectively)

System is RedHat 5.2, running linux-2.2.14 with LVM patches.

On a RedHat 6.0 system running linux-2.3.40 W/O LVM patches, /usr/bin/stat
returned expected device numbers.

I need to look into this a bit further.  More to come....

Steve Brueggeman






"Jakma, Paul" <Paul.Jakma@compaq.com> on 01/25/2000 01:07:10 PM

To:   "'Peter.Wuestefeld@resnova.de'" <Peter.Wuestefeld@resnova.de>
cc:   "'linux-lvm@msede.com'" <linux-lvm@msede.com> (bcc: Steve J Brueggeman)

Subject:  RE: [linux-lvm] LVM seems to break tar and cp "stay-local" option s



> Hi Paul,
>
> what about:
>
> cd /
> find . -print > /home/root/list
> vi list (edit to fit your wishes)
> tar -cvf- . -T /home/root/list | (cd /mynewroot; tar -xvf-)
>
> (you might want to check the tar option for "read list from file" - it
> seems to differ between distributions)
>

possible, and i did something similar in the end, eg  .... tar ... /bin /dev
/sbin ...

But the point is, why do these userland tools not recognise the boundary
between fs on ordinary device, and fs on lvm?

Also, another little issue, about partitioning:

if you change the partition table with fdisk, the kernel will not update
it's in-core idea of the partition layout if any of the partitions on that
disk are in-use, eg mounted fs or swap.

However, the kernel doesn't seem to recognise partitions that are active LVM
PV's as marking that disk in use. Ie i can repartition a disk in-use by LVM,
and the kernel does not seem to know that the disk is busy and hence will
commit the new partition table to memory.

I have a feeling LVM is forgetting to set some kind of flag that marks a
physical disk device as in-use. (and this might be related to the tar/cp
"stay-local" problem aswell). However i am not a kernel hacker... :)

regards,

Paul Jakma.

RE: [linux-lvm] LVM seems to break tar and cp "stay-local" option s

[Steve_J_Brueggeman]

Well, I've went and shot-off too quickly again.

My problem appears to be that I never upgraded my libc on my redhat-5.2 setup.

Sorry if I've caused any confusion!!!

Steve Brueggeman





Steve J Brueggeman
01/25/2000 02:19 PM

To:   "Jakma, Paul" <Paul.Jakma@compaq.com> @ INTERNET
cc:   "'linux-lvm@msede.com'" <linux-lvm@msede.com>@INTERNET

Subject:  RE: [linux-lvm] LVM seems to break tar and cp "stay-local" option s
      (Document link: Steve J Brueggeman)

Well, a quick of the tar source code reveals that they're using a stat(2) and
checking
parent_device != current_stat.st_dev

to determine if the filesystem has changed.

I just did a stat(1) on some files, (using LVM 0.7), and it always returns a
minor number of 0, no matter what Logical Volume the file I checked lives on.

Then again, I got the same result on files that reside on plain SCSI partitions
(I have root and /usr on /dev/sda1 and /dev/sda3 respectively)

System is RedHat 5.2, running linux-2.2.14 with LVM patches.

On a RedHat 6.0 system running linux-2.3.40 W/O LVM patches, /usr/bin/stat
returned expected device numbers.

I need to look into this a bit further.  More to come....

Steve Brueggeman





"Jakma, Paul" <Paul.Jakma@compaq.com> on 01/25/2000 01:07:10 PM

To:   "'Peter.Wuestefeld@resnova.de'" <Peter.Wuestefeld@resnova.de>
cc:   "'linux-lvm@msede.com'" <linux-lvm@msede.com> (bcc: Steve J Brueggeman)

Subject:  RE: [linux-lvm] LVM seems to break tar and cp "stay-local" option s



> Hi Paul,
>
> what about:
>
> cd /
> find . -print > /home/root/list
> vi list (edit to fit your wishes)
> tar -cvf- . -T /home/root/list | (cd /mynewroot; tar -xvf-)
>
> (you might want to check the tar option for "read list from file" - it
> seems to differ between distributions)
>

possible, and i did something similar in the end, eg  .... tar ... /bin /dev
/sbin ...

But the point is, why do these userland tools not recognise the boundary
between fs on ordinary device, and fs on lvm?

Also, another little issue, about partitioning:

if you change the partition table with fdisk, the kernel will not update
it's in-core idea of the partition layout if any of the partitions on that
disk are in-use, eg mounted fs or swap.

However, the kernel doesn't seem to recognise partitions that are active LVM
PV's as marking that disk in use. Ie i can repartition a disk in-use by LVM,
and the kernel does not seem to know that the disk is busy and hence will
commit the new partition table to memory.

I have a feeling LVM is forgetting to set some kind of flag that marks a
physical disk device as in-use. (and this might be related to the tar/cp
"stay-local" problem aswell). However i am not a kernel hacker... :)

regards,

Paul Jakma.

Re: [linux-lvm] LVM seems to break tar and cp "stay-local" option s

[Andi Kleen]

On Tue, Jan 25, 2000 at 02:19:21PM -0600, Steve_J_Brueggeman@notes.seagate.com wrote:
> Well, a quick of the tar source code reveals that they're using a stat(2) and
> checking
> parent_device != current_stat.st_dev
> 
> to determine if the filesystem has changed.
> 
> I just did a stat(1) on some files, (using LVM 0.7), and it always returns a
> minor number of 0, no matter what Logical Volume the file I checked lives on.
> 
> Then again, I got the same result on files that reside on plain SCSI partitions
> (I have root and /usr on /dev/sda1 and /dev/sda3 respectively)
> 
> System is RedHat 5.2, running linux-2.2.14 with LVM patches.
> 
> On a RedHat 6.0 system running linux-2.3.40 W/O LVM patches, /usr/bin/stat
> returned expected device numbers.
> 
> I need to look into this a bit further.  More to come....

This could explain some NFS failures too. dev_t is part of the nfs
filehandle given out by knfsd, when two LVs with different file systems
have the same dev_t it may chose another file with the same inode number.
Normally it does not matter because knfsd maintains a fh cache that has the
right file, but when the cache overflows or the nfs server is rebooted
it could access the file with the same ino on the wrong LV afterwards :/

-Andi

Re: [linux-lvm] LVM seems to break tar and cp "stay-local" option s

[Michael Marxmeier]

Andi Kleen wrote:
> This could explain some NFS failures too. dev_t is part of the nfs
> filehandle given out by knfsd, when two LVs with different file systems
> have the same dev_t it may chose another file with the same inode number.
> Normally it does not matter because knfsd maintains a fh cache that has the
> right file, but when the cache overflows or the nfs server is rebooted
> it could access the file with the same ino on the wrong LV afterwards :/

st_dev looks fine to me (st_rdev looks inconsistent with libc5 for
non dev files).

SuSE 6.3 (glibc 2.1.2), LVM 0.8i:

$ df /usr /var
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/vg00/usr          2031360    783652   1142852  41% /usr
/dev/vg00/var           253920     30048    210768  12% /var

$ ./stat /usr/bin/host /var/tmp/vi.recover
dev=3a00 ino=33505 mode=100755 rdev=0 /usr/bin/host
dev=3a02 ino=32809 mode=41777 rdev=0 /var/tmp/vi.recover

$ ls -l /dev/vg00
...
brw-r-----   1 root     root      58,   0 Dec 23 01:39 usr
brw-r-----   1 root     root      58,   2 Dec 23 01:39 var


SuSE 5.x (libc5), LVM 0.7:

$ df /mnt3
Filesystem         1024-blocks  Used Available Capacity Mounted on
/dev/vg00/lvol1      4098376 3605796   281024     93%   /mnt3

$ ./stat /mnt3/db/db01.vol 
dev=3a00 ino=384770 mode=100600 rdev=84b /mnt3/db/db01.vol

$ ls -l /dev/vg00
...
brw-r-----   1 root     root      58,   0 Nov 19 08:26 lvol1


Michael

-- 
Michael Marxmeier           Marxmeier Software AG
E-Mail: mike@msede.com      Besenbruchstrasse 9
Phone : +49 202 2431440     42285 Wuppertal, Germany
Fax   : +49 202 2431420     http://www.msede.com/