Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
How to determine the size of a disk
- Thread starter trifo
- Start date
As long as it's in a volume group you could use
lspv hdisk0
see Total PP's
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."
lspv hdisk0
see Total PP's
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."
- Thread starter
- #3
Hi Mike!
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.
--Trifo
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.
--Trifo
- Thread starter
- #9
Hi!
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%.
--Trifo
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%.
--Trifo
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%)
HTH,
p5wizard
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%)
HTH,
p5wizard
- Status
Similar threads
- Locked
- Question