In the writing of a statistics script rose the need to determine the exact size of a hdisk. I would need a general way to to this, which works even on SAN disks (SDD and SDDPCM) and simple SCSI disks as well. Can you tell me such method?
for i in `lspv | awk '{print $1}'`
do
lspv $i
done
Mike
"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."
Well, it was one of my first thoughts as well. However it is not suitable for me, as there are a bunch of disks in GPFS use which do not have PVID and VG assignement, thus lspv throws an error.
I would need some general method. Some ODM query or SCSI magic or whatever.
"Whenever I dwell for any length of time on my own shortcomings, they gradually begin to seem mild, harmless, rather engaging little things, not at all like the staring defects in other people's characters."
Thanks for the tips, especially p5wizard for the bootinfo -s. Even though I will need to use the output of "pcmpath/datapath query essmap" and some string manipulation magic, as I will need to collect LUN id-s along with disk sizes.
Even though there are some oddnesses around disk sizes: when I allocate a 50GB LUN for an AiX 5.2 host with SDDPCM, pcmpath reports its size as 47.7GB. The same 50GB LUN appears on an AiX 4.3 host with SDD as 50.0GB.
There are also differences in the output of getconf/bootinfo and also in the lsvg -p reports. The differences reach 5-6%.
ESS LUNs are created in 10^9 GB sizes (0.1 increment)
DS6k/DS8k LUNs are created in 2^30 GB sizes (and best is to use 1GB increments, otherwise you're wasting space inside the DS6k/DS8k, because allocation is on 1GB boundaries)
SDDPCM assumes DS6k/DS8k LUNs and takes the disk size in MB, divides by 1024 to get GB value. So you get a wrong value if you use SDDPCM for ESS LUNs
SDD assumes ESS LUNs and takes disk size in MB, divides by 1000 to get GB value - again wrong values if SDD is used for DS6k/DS8k LUNs.
If your script uses bootinfo and divides by 1024 you should get a correct value which corresponds with the lsvg -p size.
Also, PV size will allways be a multiple of the PP size. For large PP size, you can lose some of the disk's MBs.
PP size of 128MB -> max loss is 127.999MB if the last PP doesn't fit.
a SCSI disk of 36GB is a bit more than 36400 MB (x 1000000) - at least that's what lscfg says - but put it in a VG and you start dividing it in 1024s instead of 1000s - this also gives a difference of 5%. In a 64MB PP VG you get 542 PPs = 34688 MBs (x 1024 x 1024) (diff of 4.7%)
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.