What is the VGID file in /etc/vg for?
Rajesh Malhotra
Fellow AIXers,
The directory /etc/vg contains a file vg<VGID> for each
of the VG in the system. What is this file for? Does'nt all the VG related
info reside in the ODM?
Also if you exportvg a VG, the info for that VG gets removed
from the system, but the /etc/vg/vg<VGID> file fir that VG get left
behind. Is there a problem if this file is physically removed?
Will there be a problem in a subsequent import of the VG?
I would appreciate any responses to the above questions.
Thanx,
Raj.
--
===============================================================================
__ __ .
/ __/ / Raj Malhotra.
/ ( /_ / voice : (908)613 4313.
__/ email : manm...@gauss.rutgers.edu
===============================================================================
Julie L. Craft
>
>Fellow AIXers,
>
> The directory /etc/vg contains a file vg<VGID> for each
>of the VG in the system. What is this file for? Does'nt all the VG related
>info reside in the ODM?
No, it contains basically a copy of the VGDA that is on
the disk. This file is maintained by liblvm.a for faster
response on lvm commands. That way you don't have to
go to the disk every time for a query. If you remove this
file it will be automatically rebuilt the next time you
run an LVM command.
>
> Also if you exportvg a VG, the info for that VG gets removed
>from the system, but the /etc/vg/vg<VGID> file fir that VG get left
>behind. Is there a problem if this file is physically removed?
This bug has been fixed with ix22650
abstract ENTRIES IN /ETC/VG ARE NOT REMOVED WHEN THEY ARE OUTDATED,
delta 1.21.1.5 com/cmd/bsys/mksysb.sh
delta 1.17.1.1 com/cmd/lvm/highcmd/exportvg.sh
delta 1.7.1.2 com/lib/lvm/varyoffvg.c
>
> Will there be a problem in a subsequent import of the VG?
>
> I would appreciate any responses to the above questions.
>
>Thanx,
>
>Raj.
Later,
Julie
--
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Julie Levell Craft IBM AUSTIN,TX Internet: ju...@aixwiz.austin.ibm.com
IBMNET: JULIEL at AUSVM6 2F-007/903 (512) 838-2677 (Tie 678-2677)
"I'm not getting defensive!"
Fred R Stearns
>In article <Sep.3.12.58....@gauss.rutgers.edu> manm...@gauss.rutgers.edu (Rajesh Malhotra) writes:
>>
>>Fellow AIXers,
>>
>> The directory /etc/vg contains a file vg<VGID> for each
>>of the VG in the system. What is this file for? Does'nt all the VG related
>>info reside in the ODM?
>
> No, it contains basically a copy of the VGDA that is on
> the disk. This file is maintained by liblvm.a for faster
> response on lvm commands. That way you don't have to
> go to the disk every time for a query. If you remove this
> file it will be automatically rebuilt the next time you
> run an LVM command.
Now that's silly. Instead of going to the disk to get the VGDA,
you go to the disk to get the VGDA. Okay, Okay, so maybe it will
be buffered up in physical memory by jfs and the vmm, but it
would seem that it would only stay buffered if you were accessing
it alot.
>
> Later,
> Julie
>--
>*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
>Julie Levell Craft IBM AUSTIN,TX Internet: ju...@aixwiz.austin.ibm.com
>IBMNET: JULIEL at AUSVM6 2F-007/903 (512) 838-2677 (Tie 678-2677)
>"I'm not getting defensive!"
--
Fred R. Stearns -- fr...@dickens.com
Everything's a kludge!
Craig Miller
>In article <1992Sep4.2...@awdprime.austin.ibm.com> ju...@levell.austin.ibm.com (Julie L. Craft) writes:
>>In article <Sep.3.12.58....@gauss.rutgers.edu> manm...@gauss.rutgers.edu (Rajesh Malhotra) writes:
>>>
>>>Fellow AIXers,
>>>
>>> The directory /etc/vg contains a file vg<VGID> for each
>>>of the VG in the system. What is this file for? Does'nt all the VG related
>>>info reside in the ODM?
>>
>> No, it contains basically a copy of the VGDA that is on
>> the disk. This file is maintained by liblvm.a for faster
>> response on lvm commands. That way you don't have to
>> go to the disk every time for a query. If you remove this
>> file it will be automatically rebuilt the next time you
>> run an LVM command.
>
>Now that's silly. Instead of going to the disk to get the VGDA,
>you go to the disk to get the VGDA. Okay, Okay, so maybe it will
>be buffered up in physical memory by jfs and the vmm, but it
>would seem that it would only stay buffered if you were accessing
>it alot.
Now this *is* getting silly.
What you're assuming is that getting the VGDA is quick and
easy. Wrong. If lvm had to figure out which VGDA to use
each time it needed it, you'd lose big time.
Instead, it does the dirty work once (at varyon time).
Trust Julie. I think I can safely say that Julie knows
more about lvm than either of us. /etc/vg *is* quicker
than going directly to the /dev/hdisk* entries and trying
to find the correct VGDA to use.
>Fred R. Stearns -- fr...@dickens.com
Craig
--
Craig Miller, software mechanic - AIXV3 Change Team (Level3 support)
dcm%codesmith.au...@ibmpa.awdpa.ibm.com
"I do not represent IBM. They wouldn't let me."
Fred R Stearns
>>>>of the VG in the system. What is this file for? Does'nt all the VG related
>>>>info reside in the ODM?
>>>
>>> No, it contains basically a copy of the VGDA that is on
>>> the disk. This file is maintained by liblvm.a for faster
>>> response on lvm commands. That way you don't have to
>>> go to the disk every time for a query. If you remove this
>>> file it will be automatically rebuilt the next time you
>>> run an LVM command.
>>
>>Now that's silly. Instead of going to the disk to get the VGDA,
>>you go to the disk to get the VGDA. Okay, Okay, so maybe it will
>>be buffered up in physical memory by jfs and the vmm, but it
>>would seem that it would only stay buffered if you were accessing
>>it alot.
>
> Now this *is* getting silly.
>
> What you're assuming is that getting the VGDA is quick and
> easy. Wrong. If lvm had to figure out which VGDA to use
> each time it needed it, you'd lose big time.
Whoa! Chill out! I was just going by what she said! Just go
back up and read her paragraph above. Besides, I was just going
for a little humor. If you wanna get serious about it . . .
On my 320, I lose about .55 seconds (real-time) for "lsvg -l myvg".
And I also get a 230K file in my rootvg. user and sys times are
fairly close to the same. So is this half a second the "big
time" that I lose? That 230K is already stored on my disk. In
fact, I have 3 disks in that VG, so there are actually like 3 or
4 copies (or is it more?) of the same information stored on my
system. And I get to have another copy in my root file system.
(Note: 230K is just one of my vgVGID files for one of my volume
groups. I have two volume groups. The rootvg file is only 56K.
But ... I also had 4 other vgVGID files lying around in my /etc/vg
that weren't needed anymore. Those four files used up about half
a meg.)
No, that is not what I'm assuming. All she said was that she put
it in a file so she wouldn't have to go to disk to get it.
Besides, if you ask the pfs and vmm guys, they'll say that
accessing a file isn't really all that easy. You've gotta map
the file into virtual memory, and then when you read the file
you have all these page faults that you have to process. And
there are two translations that must happen, the file-system
translation and the lvm translation.
No, I'm not saying that it's easy. But it could be made easy.
Maybe she should just save the location of the "correct" VGDA,
instead of the entire thing. What would saving the location require?
Knowing which hdisk and what offset on that hdisk? That could be
saved in 2 longs in lvm kernel space, one long for major/minor
and the other for block offset. Or you could save the name of the
hdisk and the offset. Make it a 64 character pathname and a long.
But instead I get 230K in /etc/vg. Then, to access the VGDA would
only require reading the hdisk directly; no FS translation, and
no LV translation.
>
> Instead, it does the dirty work once (at varyon time).
>
> Trust Julie. I think I can safely say that Julie knows
> more about lvm than either of us. /etc/vg *is* quicker
> than going directly to the /dev/hdisk* entries and trying
> to find the correct VGDA to use.
Just because Julie knows more about lvm than we do does not mean
that having that file lying around is the right thing to do.
>
>>Fred R. Stearns -- fr...@dickens.com
>
> Craig
>--
>Craig Miller, software mechanic - AIXV3 Change Team (Level3 support)
> dcm%codesmith.au...@ibmpa.awdpa.ibm.com
> "I do not represent IBM. They wouldn't let me."
--
Fred R. Stearns -- fr...@dickens.com
Everything's a kludge!