cplv - a few questions

[ogniemi]

Hello,

I have copied LV from rootvg to trainvg. (The copying process completed successfully), but have no idea how to create the fs on new LV to have updated ODM. Doing it from "smitty fs" created empty FS - there should be the data as in source LV.

When I am doing it by editing /etc/filesystems the data in FS are present but I guess re-importing the "trainvg" will cause removing entries I put in /etc/filesystems and the FS.

Please tell me how to created the FS on LV created by "cplv" to not lose the data and have updated VGDAs.

regards,
Mark

 

[MoshiachNow]

Hi,

You should choose the following path from smit :

smit fs -> addd FS -> Journaled -> Add a Journaled File System on a Previously Defined Logical Volume

"Long live king Moshiach !"

http://www.7for70.com/

 

[ogniemi]

Hello,

Nope. I did it on the beginning and it creates new, empty filesystem. I am expecting data as in source LV,


regards,
Mark

 

[MoshiachNow]

Have tried:

1.synclvodm trainvg <NEW-LV>

and then adding a FS on top ?

2.Also - please post the results of :

lslv -L <NEW-LV>

&quot;Long live king Moshiach !&quot;

http://www.7for70.com/

 

[ogniemi]

# ls /home
guest lost+found sshd
# umount /home
# cplv -v trainvg hd1
cplv: Logical volume hd1 successfully copied to fslv00 .

# synclvodm trainvg fslv00
# lslv -L fslv00
LOGICAL VOLUME: fslv00 VOLUME GROUP: trainvg
LV IDENTIFIER: 0038412a00004c00000000f8c51bdbd3.1 PERMISSION: read/write
VG STATE: active/complete LV STATE: closed/syncd
TYPE: jfs WRITE VERIFY: off
MAX LPs: 512 PP SIZE: 32 megabyte(s)
COPIES: 1 SCHED POLICY: parallel
LPs: 4 PPs: 4
STALE PPs: 0 BB POLICY: relocatable
INTER-POLICY: minimum RELOCATABLE: yes
INTRA-POLICY: center UPPER BOUND: 32
MOUNT POINT: N/A LABEL: /home
MIRROR WRITE CONSISTENCY: on/ACTIVE
EACH LP COPY ON A SEPARATE PV ?: yes
Serialize IO ?: NO

# crfs -v jfs -d'fslv00' -m'/trainhome' -A'no' -p'rw' -t'no' -a frag='4096' -a nbpi='4096' -a ag='8'
Based on the parameters chosen, the new /trainhome JFS file system
is limited to a maximum size of 134217728 (512 byte blocks)

New File System size is 262144
root@fradev91 /dev/pts/0 /
# lsvg -l trainvg
trainvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
fslv00 jfs 4 4 1 closed/syncd /trainhome
loglv00 jfslog 1 1 1 closed/syncd N/A
# mount /trainhome
# ls /trainhome
lost+found
#

 

[ogniemi]

I found some soultion, here it is:

# df
Filesystem 512-blocks Free %Used Iused %Iused Mounted on
/dev/hd4 131072 84928 36% 2485 8% /
/dev/hd2 2359296 23040 100% 29372 10% /usr
/dev/hd9var 262144 230480 13% 525 2% /var
/dev/hd3 655360 220912 67% 135 1% /tmp
/proc - - - - - /proc
/dev/hd10opt 131072 77576 41% 1019 7% /opt
/dev/fslv01 262144 253504 4% 31 1% /home
# umount /home
# cplv -v rootvg fslv01
cplv: Logical volume fslv01 successfully copied to fslv02 .
root@fradev91 /dev/pts/0 /
# lsvg -l rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 1 1 closed/syncd N/A
hd6 paging 8 8 1 open/syncd N/A
hd8 jfslog 1 1 1 open/syncd N/A
hd4 jfs 1 1 1 open/syncd /
hd2 jfs 18 18 1 open/syncd /usr
hd9var jfs 2 2 1 open/syncd /var
hd3 jfs 5 5 1 open/syncd /tmp
fslv02 jfs 2 2 1 closed/syncd N/A
hd10opt jfs 1 1 1 open/syncd /opt
# lsvg -l trainvg
trainvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
fslv00 jfs 4 4 1 closed/syncd /trainhome
loglv00 jfslog 1 1 1 closed/syncd N/A
fslv01 jfs 4 4 1 closed/syncd /home
# rmfs /home
rmlv: Logical volume fslv01 is removed.
# cplv -v trainvg fslv02
cplv: Logical volume fslv02 successfully copied to fslv01 .
# lsvg -l trainvg
trainvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
fslv00 jfs 4 4 1 closed/syncd /trainhome
loglv00 jfslog 1 1 1 closed/syncd N/A
fslv01 jfs 4 4 1 closed/syncd N/A
# varyoffvg trainvg
# exportvg trainvg
# importvg -y trainvg hdisk1
trainvg
# lsvg -l trainvg
trainvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
fslv00 jfs 4 4 1 closed/syncd /trainhome
loglv00 jfslog 1 1 1 closed/syncd N/A
fslv01 jfs 4 4 1 closed/syncd /home
# ls /home
# mount /home
# ls /home
guest lost+found sshd
#
# lspv
hdisk0 0038412a81387d6b rootvg active
hdisk1 0038412a8184e0b5 trainvg active
# lslv -l fslv01
fslv01:/home
PV COPIES IN BAND DISTRIBUTION
hdisk1 004:000:000 100% 000:000:004:000:000

 

[donttreadonme]

Why not just mount the new LV on the same filesystem it had?

 

[sunnytiger]

Try to add a new entry in /etc/filesystem pointing to new directory, then mount the new fs.

 

[ogniemi]

I don't want to touch manually /etc/filesystems because my hand made changes will be overwritten when I exportvg/importvg...

It is necessary to remove the old fs/LV first if not it will complain during reimporting newVG that the mount point is used. And the mount point is storet in LVCB of new LV and it is the same as in old LV.

Maybe (I didn't check it) the other soulution would be the following:

1. edit /etc/filesystems - add new stanza for new FS build on new copy of LV (of course fjslog and mount point has to be another one)
2. made change of FS (smitty fs) to update the LVCB of the LV


And here is the information about LVCB:

The logical volume control block (LVCB) is the first 512 bytes of a logical volume. This area holds important information such as the creation date of the logical volume, information about mirrored copies, and possible mount points in the journaled filesystem (JFS). Certain LVM commands are required to update the LVCB, as part of the algorithms in LVM. The old LVCB is read and analyzed to see if it is a valid. If the information is valid LVCB information, the LVCB is updated. If the information is not valid, the LVCB update is not performed and the user is given the warning message:
Warning, cannot write lv control block
data.
Most of the time, this is a result of database programs accessing raw logical volumes (and bypassing the JFS) as storage media. When this occurs, the information for the database is literally written over the LVCB. Although this may seem fatal, it is not the case. Once the LVCB is overwritten, the user can still:
Expand a logical volume
Create mirrored copies of the logical volume
Remove the logical volume
Create a journaled filesystem to mount the logical volume
There are limitations to deleting LVCBs. The logical volumes with deleted LVCB's face possible, incomplete importation into other AIX systems. During an importvg, the LVM command will scan the LVCB's of all defined logical volumes in a volume group for information concerning the logical volumes. If the LVCB is deleted, the imported volume group will still define the logical volume to the new AIX system, which, is accessing this volume group, and the user can still access the raw logical volume. However, any journaled filesystem information is lost and the associated mount point won't be imported into the new AIX system. The user must create new mount points and the availability of previous data stored in the filesystem is not assured. Also, During this import of logical volume with an erased LVCB, some non-jfs information concerning the logical volume, which is displayed by the lslv command, cannot be found. When this occurs, the system uses default logical volume information to populate the logical volume's ODM information. Thus, some output from lslv will be inconsistent with the real logical volume. If any logical volume copies still exist on the original disks, the information will not be correctly reflected in the ODM database. The user should use the rmlvcopy and mklvcopy commands to rebuild any logical volume copies and synchronize the ODM.


regards,
Chris

 

[donttreadonme]

Look people, if you had:
lv01 mounted over /test

then you did:
cplv lv01 lv01_new

all that needs to be done is:
chfs -a dev=/dev/lv01_new -a log=/dev/logdevice /test

 

[ogniemi]

yes indeed!

thx for the hint!


rgrds,M.