disk device utilization - Veritas Volume Manager

This is a discussion on disk device utilization - Veritas Volume Manager ; Dear All, Is there any way we can find disk utilization details from command line. From VEA GUI we can see how much % disk space is being utilized but I am looking for any solution through command line. I ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: disk device utilization

  1. disk device utilization


    Dear All,

    Is there any way we can find disk utilization details from command line.
    From VEA GUI we can see how much % disk space is being utilized but I am
    looking for any solution through command line.

    I tried with vxprint outout but it really difficult to calcute the same.



  2. Re: disk device utilization

    vxdg free

    Sandip wrote:
    > Dear All,
    >
    > Is there any way we can find disk utilization details from command line.
    > From VEA GUI we can see how much % disk space is being utilized but I am
    > looking for any solution through command line.
    >
    > I tried with vxprint outout but it really difficult to calcute the same.
    >
    >


  3. Re: disk device utilization


    Thanks,

    When I am giving vxdg free it is showing following output..

    root:> vxdg free
    GROUP DISK DEVICE TAG OFFSET LENGTH FLAGS
    rootdg rootd01 c4t0d0 c4t0d0 8388608 9388462 -

    swdg disk01 c4t7d0 c4t7d0 16824624 952446 -


    Does that output means swdg disk c4t7d0 has only 950MB available ? What about
    other disk in swdg ? Do that mean that disk is 100% full.



    Me wrote:
    >vxdg free
    >
    >Sandip wrote:
    >> Dear All,
    >>
    >> Is there any way we can find disk utilization details from command line.
    >> From VEA GUI we can see how much % disk space is being utilized but I

    am
    >> looking for any solution through command line.
    >>
    >> I tried with vxprint outout but it really difficult to calcute the same.
    >>
    >>



  4. Re: disk device utilization

    The size free is in number of 512 byte blocks.

    vxdg free shows only what is free.

    OK, so you don't believe what you saw ?
    Just have to calculate a bit.

    do "vxprint -th"

    This will show you all the diskgroups and all the disks in that diskgroup.

    Let's take rootdg. It will show you how many disks youve got, the size
    of the disks and then the volumes. Each volume will show you the
    sub-disks (sd lines) where you can then go and calculate what is being
    used on each disk.

    So, go ahead and do the maths and see if you come to the same conclusion
    as vxdg free.

    If you don't know what I'm talking about, then post the output of
    "vxprint -th" here and I will show you how to calculate.

    Sandip wrote:
    > Thanks,
    >
    > When I am giving vxdg free it is showing following output..
    >
    > root:> vxdg free
    > GROUP DISK DEVICE TAG OFFSET LENGTH FLAGS
    > rootdg rootd01 c4t0d0 c4t0d0 8388608 9388462 -
    >
    > swdg disk01 c4t7d0 c4t7d0 16824624 952446 -
    >
    >
    > Does that output means swdg disk c4t7d0 has only 950MB available ? What about
    > other disk in swdg ? Do that mean that disk is 100% full.
    >
    >
    >
    > Me wrote:
    >
    >>vxdg free
    >>
    >>Sandip wrote:
    >>
    >>>Dear All,
    >>>
    >>>Is there any way we can find disk utilization details from command line.
    >>>From VEA GUI we can see how much % disk space is being utilized but I

    >
    > am
    >
    >>>looking for any solution through command line.
    >>>
    >>>I tried with vxprint outout but it really difficult to calcute the same.
    >>>
    >>>

    >
    >


  5. Re: disk device utilization


    Hi Me,

    Thanks for your reply. I am just trying to understand how I can calculate
    disk spcae utilization from command line. Thanks for 512 byte block info.
    I used think it is 1024 byte block.

    Can you please help me to understand the following output.

    GROUP DISK DEVICE TAG OFFSET LENGTH FLAGS
    rootdg rootd01 c4t0d0 c4t0d0 8388608 9388462 -
    swdg disk01 c4t7d0 c4t7d0 16824624 952446
    -

    In the above output I understand OFFSET means if I want to create any new
    volume then it would be that sector position. What about LENGTH ? Does that
    mean 952446/2 would be total bytes available.

    Thanks for your advise.




    Me wrote:
    >The size free is in number of 512 byte blocks.
    >
    >vxdg free shows only what is free.
    >
    >OK, so you don't believe what you saw ?
    >Just have to calculate a bit.
    >
    >do "vxprint -th"
    >
    >This will show you all the diskgroups and all the disks in that diskgroup.
    >
    >Let's take rootdg. It will show you how many disks youve got, the size
    >of the disks and then the volumes. Each volume will show you the
    >sub-disks (sd lines) where you can then go and calculate what is being
    >used on each disk.
    >
    >So, go ahead and do the maths and see if you come to the same conclusion


    >as vxdg free.
    >
    >If you don't know what I'm talking about, then post the output of
    >"vxprint -th" here and I will show you how to calculate.
    >
    >Sandip wrote:
    >> Thanks,
    >>
    >> When I am giving vxdg free it is showing following output..
    >>
    >> root:> vxdg free


    >> >>

    >>
    >> Does that output means swdg disk c4t7d0 has only 950MB available ? What

    about
    >> other disk in swdg ? Do that mean that disk is 100% full.
    >>
    >>
    >>
    >> Me wrote:
    >>
    >>>vxdg free
    >>>
    >>>Sandip wrote:
    >>>
    >>>>Dear All,
    >>>>
    >>>>Is there any way we can find disk utilization details from command line.
    >>>>From VEA GUI we can see how much % disk space is being utilized but I

    >>
    >> am
    >>
    >>>>looking for any solution through command line.
    >>>>
    >>>>I tried with vxprint outout but it really difficult to calcute the same.
    >>>>
    >>>>

    >>
    >>



  6. Re: disk device utilization

    OK, the 512 byte blocks, is what Volume Manager deals with. Whenever it
    does IO, it will do so in 512 byte blocks. So every 2 blocks, will give
    you 1K. The erst of the calculations work from there.

    Now, the offset.

    Every disk under Volume Manager control, needs to keep some "private"
    information. This is stuff like, which diskgroup do I belong to ? What
    is my name (like rootd01), and where do I fit into the different
    volumes. This information can not be kept where your data is kept (as
    mentioned it is "private" to Volume Manager.

    So, on each disk that Volume Manager controls, there is a "private"
    area. This could be on a slice (on Solaris do "prtvtoc" on the disk and
    look for the slice with a tag of "15". This slice keeps the private
    information.

    Normally on a sliced disk, the user data is kept in a seperate slice
    (called the public slice). This is indicated with a tag of "14" in the
    prtvtoc.

    The biggest issue is that not all disks are sliced (with slices). There
    a disks with only 1 slice (AIX people will know what I'm talking about
    now). There might also be good reasons why we would like to see a disk
    as "without slices" (on Solaris, if you look only at slice 2 - the whole
    disk). The reasons would be CDS (Common-platform Data Sharing), which
    allows you to take the (Volume Manager) Disk between different systems
    (thus between a AIX system and Solaris or even Linux), and Volume
    Manager will understand the (private) data on the disk.

    Where the we don't have slices, the public data (your data) and the
    Volume Manager data (the private data), can thus only be on the same
    slice. Thus, Volume Manager needs to keep track of this. It "defines"
    (in it's own configuration) an area where the public data begins. (This
    is fixed and can not be moved once the disk has been placed under Volume
    Manager control). The offset from then onwards, indicates the number of
    512 byte blocks into the public area.



    So, let's look at the output of vxprint again. Just an example:



    # vxprint -ht -g testdg


    DG NAME NCONFIG NLOG MINORS GROUP-ID
    DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE
    RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL
    RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK
    V NAME RVG KSTATE STATE LENGTH USETYPE PREFPLEX RDPOL
    PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE
    SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE
    SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE




    dg testdg default default 84000 970356463.1203.alu

    dm testdg01 c1t4d0s2 sliced 2179 8920560 -
    dm testdg02 c1t6d0s2 sliced 2179 8920560 -

    v test - ENABLED ACTIVE 17840128 fsgen - SELECT
    pl test-01 test ENABLED ACTIVE 17841120 CONCAT - RW
    sd testdg01-01 test-01 testdg01 0 8920560 0 c1t4d0 ENA
    sd testdg02-01 test-01 testdg02 0 8920560 8920560 c1t6d0 ENA



    --------------------

    OK, apart from the headers (printed with the"h" option), we see :


    dm testdg01 c1t4d0s2 sliced 2179 8920560 -
    dm testdg02 c1t6d0s2 sliced 2179 8920560 -

    (The header will show the columns
    (DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE )

    OK, these are the disks in the Disk Group. We see their Volume Manager
    names (testdg01 and testdg02), their real device names (c1t4d0 and
    c1t6d0), which can change at any time (adding new controllers or new
    disks or .....). We also see that the disks are sliced (explained above)
    and that the private region is 2179 bytes big (normally the size of 1
    cylinder on the disk) and the public area is 8920560 x 512 byte blocks big



    A line starting with "v" indicating the volume:

    (from the header
    (V NAME RVG KSTATE STATE LENGTH USETYPE PREFPLEX RDPOL)



    v test - ENABLED ACTIVE 17840128 fsgen - SELECT



    We see the name is "test", the Volume is ENABLED ACTIVE , which means we
    can read from it and write to it (if permissions allow) and we see the
    size of the volume (17840128 blocks of 512 bytes). Lastly we see what
    this volume will be used for. General Filesystems (fsgen).


    OK, the next line gives us the plex. A plex = mirror. In this case we
    have only one plex (one line starting with "pl". The plex line will also
    give us the layout of the volume:

    (from the header: )
    (PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE)


    pl test-01 test ENABLED ACTIVE 17841120 CONCAT - RW


    OK, so we see the plex name is "test-01" and it is part of higher object
    (or volume) called "test". We see the plex is ENABLED ACTIVE, which
    means this mirror is good (in some cases where you ahve more than 1 plex
    or mirror, 1 might be good and the other bad - which you can recover).
    We also see the size of the plex (17841120 x 512byte blocks). The plex
    is a bit bigger than the volume due to rounding.


    Next we see that the plex has data on 2 disks (or sub-disks). A sub-disk
    is a logical part of the public area that can be addressed. This can be
    as small as 1 x 512 byte block, and there are almost no limits to the
    number of sub-disks that can be created on a single disk.

    So, let's look at the sub-disks on our 2 physical disks (we know we have
    2 disks in the disk group)

    (From the header in vxprint
    (SD NAME PLEX DISK DISKOFFS LENGTH COL/]OFF DEVICE MODE)



    sd testdg01-01 test-01 testdg01 0 8920560 0 c1t4d0 ENA
    sd testdg02-01 test-01 testdg02 0 8920560 8920560 c1t6d0 ENA



    Sub-disk lines start with "sd" and then the name of the sub-disk. This
    name can be changed, but generally the name will be the name of the disk
    (as Volume Manager sees it) followed by a "-" followed by the number
    of the subdisk (starting at 01, then 02, then 03 ,.......)

    So, we see that testdg01-01 is the first subdisk on the disk called
    testdg01. We also see that this sub-disk forms patr of the higher order
    object (in this case a plex) called "test-01" and we can see that this
    sub-disk is part of the disk called "testdg01" (well, we know that
    already). We also see teh diskoffset (or how far into the public region
    this sub-disk starts) as well as the length of the sub-disk (8920560 x
    512 byte blocks in our case).

    The next column can be used for counting columns (like in a stripe or in
    a RAID 5), or will only tell us the offset into the plex (like what it
    does in this case), where this sub-disk keeps the data for.



    OK, and you did not even know that you would get such a lot out of
    vxprint. From the above we can see that the whole disk (for both the
    disks) are used in sub-disks (see length of the disks in the "dm" line
    and take away what has been used in all "sd" lines mentioning the disk).

    So, from our calculations, youcan see that the whole disk is used (for
    both disks). This is what I mentioned, you can calculate the stuff
    yourself if you want to. That is also why I said if you post a vxprint
    here, I will do it for you or show you how it is done.


    ------
    OK, having said all that, let's look at your output of vxdg free

    We see that in the diskgroup called rootdg, there is only 1 disk with
    free space, and that is the disk called "rootd01" and this disk has some
    space starting at offset 8388608 blocks into the public area and with
    length of 9388462 x 512 byte blocks (no flags, means no reservations or
    that it has been marked bad or anything like that).

    The same can be seen for a disk called "disk01" in a diskgroup called
    "swdg".

    If you do not belive the output of vxdg free, please calculate for
    yourself by adding the sizes of all the sub-disks on each disk and then
    see if there is anything left from the size of the disk (all of which
    can be seen in the vxprint outputs)

    By all means go ahead and do it !! You will only go through the
    calculations once in your life to find that the vxdg free has been right
    all along (or someone else would have reported it to Veritas ages ago,
    this commands has been around since version 2.x)





    Sandip wrote:
    > Hi Me,
    >
    > Thanks for your reply. I am just trying to understand how I can calculate
    > disk spcae utilization from command line. Thanks for 512 byte block info.
    > I used think it is 1024 byte block.
    >
    > Can you please help me to understand the following output.
    >
    > GROUP DISK DEVICE TAG OFFSET LENGTH FLAGS
    > rootdg rootd01 c4t0d0 c4t0d0 8388608 9388462 -
    > swdg disk01 c4t7d0 c4t7d0 16824624 952446
    > -
    >
    > In the above output I understand OFFSET means if I want to create any new
    > volume then it would be that sector position. What about LENGTH ? Does that
    > mean 952446/2 would be total bytes available.
    >
    > Thanks for your advise.
    >
    >
    >
    >
    > Me wrote:
    >
    >>The size free is in number of 512 byte blocks.
    >>
    >>vxdg free shows only what is free.
    >>
    >>OK, so you don't believe what you saw ?
    >>Just have to calculate a bit.
    >>
    >>do "vxprint -th"
    >>
    >>This will show you all the diskgroups and all the disks in that diskgroup.
    >>
    >>Let's take rootdg. It will show you how many disks youve got, the size
    >>of the disks and then the volumes. Each volume will show you the
    >>sub-disks (sd lines) where you can then go and calculate what is being
    >>used on each disk.
    >>
    >>So, go ahead and do the maths and see if you come to the same conclusion

    >
    >
    >>as vxdg free.
    >>
    >>If you don't know what I'm talking about, then post the output of
    >>"vxprint -th" here and I will show you how to calculate.
    >>
    >>Sandip wrote:
    >>
    >>>Thanks,
    >>>
    >>>When I am giving vxdg free it is showing following output..
    >>>
    >>>root:> vxdg free

    >
    >
    >>>>>
    >>>
    >>>
    >>>Does that output means swdg disk c4t7d0 has only 950MB available ? What

    >
    > about
    >
    >>>other disk in swdg ? Do that mean that disk is 100% full.
    >>>
    >>>
    >>>
    >>>Me wrote:
    >>>
    >>>
    >>>>vxdg free
    >>>>
    >>>>Sandip wrote:
    >>>>
    >>>>
    >>>>>Dear All,
    >>>>>
    >>>>>Is there any way we can find disk utilization details from command line.
    >>>>
    >>>>>From VEA GUI we can see how much % disk space is being utilized but I
    >>>
    >>>am
    >>>
    >>>
    >>>>>looking for any solution through command line.
    >>>>>
    >>>>>I tried with vxprint outout but it really difficult to calcute the same.
    >>>>>
    >>>>>
    >>>
    >>>

    >


  7. Re: disk device utilization


    Me,

    Thanks a lot for your kind brief explanation. I really appreciate the same.
    It gave me a great knowledge.

    We use all the Veritas products on our HP-UX boxes.

    I tried to do the following test where it seems it prints 1024 bytes block
    rather than 512. Please pardon me for my ignorance I am just trying to understand
    this layout my level best.

    root [/]: diskinfo /dev/rdsk/c5t0d4
    SCSI describe of /dev/rdsk/c5t0d4:
    vendor: HP
    product id: OPEN-E
    type: direct access
    size: 14226480 Kbytes
    bytes per sector: 512

    Now if I see vxprint output it seems it shows 1K block as per the dm tst01
    output.

    root[/]: vxprint -g testdg -ht

    DG NAME NCONFIG NLOG MINORS GROUP-ID

    DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE

    RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL

    RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK

    V NAME RVG KSTATE STATE LENGTH READPOL PREFPLEX
    UTYPE
    PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID
    MODE
    SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE
    MODE
    SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM
    MODE
    DC NAME PARENTVOL LOGVOL

    SP NAME SNAPVOL DCO



    dg testdg default default 6013000 1143447102.1344.testserver



    dm tst01 c5t0d4 simple 1024 14223040 -


    Now when I create any volume as like following.
    root@pluto [/]: vxassist -g testdg make testvol 2G
    root@pluto [/]: vxprint -g testdg -ht

    DG NAME NCONFIG NLOG MINORS GROUP-ID

    DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE

    RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL

    RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK

    V NAME RVG KSTATE STATE LENGTH READPOL PREFPLEX
    UTYPE
    PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID
    MODE
    SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE
    MODE
    SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM
    MODE
    DC NAME PARENTVOL LOGVOL

    SP NAME SNAPVOL DCO



    dg testdg default default 6013000 1143447102.1344.pluto



    dm tst01 c5t0d4 simple 1024 14223040 -



    v testvol - ENABLED ACTIVE 2097152 SELECT -
    fsgen
    pl testvol-01 testvol ENABLED ACTIVE 2097152 CONCAT -
    RW
    sd tst01-01 testvol-01 tst01 0 2097152 0 c5t0d4
    ENA

    In the volume column it is showing 2097152 block which if I calcuclate 2097152/1024
    then it seems it is showing current 2GB output.

    Could you please advise me again if I wrong.



    Me wrote:
    >OK, the 512 byte blocks, is what Volume Manager deals with. Whenever it


    >does IO, it will do so in 512 byte blocks. So every 2 blocks, will give


    >you 1K. The erst of the calculations work from there.
    >
    >Now, the offset.
    >
    >Every disk under Volume Manager control, needs to keep some "private"
    >information. This is stuff like, which diskgroup do I belong to ? What
    >is my name (like rootd01), and where do I fit into the different
    >volumes. This information can not be kept where your data is kept (as
    >mentioned it is "private" to Volume Manager.
    >
    >So, on each disk that Volume Manager controls, there is a "private"
    >area. This could be on a slice (on Solaris do "prtvtoc" on the disk and


    >look for the slice with a tag of "15". This slice keeps the private
    >information.
    >
    >Normally on a sliced disk, the user data is kept in a seperate slice
    >(called the public slice). This is indicated with a tag of "14" in the
    >prtvtoc.
    >
    >The biggest issue is that not all disks are sliced (with slices). There


    >a disks with only 1 slice (AIX people will know what I'm talking about
    >now). There might also be good reasons why we would like to see a disk
    >as "without slices" (on Solaris, if you look only at slice 2 - the whole


    >disk). The reasons would be CDS (Common-platform Data Sharing), which
    >allows you to take the (Volume Manager) Disk between different systems
    >(thus between a AIX system and Solaris or even Linux), and Volume
    >Manager will understand the (private) data on the disk.
    >
    >Where the we don't have slices, the public data (your data) and the
    >Volume Manager data (the private data), can thus only be on the same
    >slice. Thus, Volume Manager needs to keep track of this. It "defines"
    >(in it's own configuration) an area where the public data begins. (This


    >is fixed and can not be moved once the disk has been placed under Volume


    >Manager control). The offset from then onwards, indicates the number of


    >512 byte blocks into the public area.
    >
    >
    >
    >So, let's look at the output of vxprint again. Just an example:
    >
    >
    >
    ># vxprint -ht -g testdg
    >
    >
    >DG NAME NCONFIG NLOG MINORS GROUP-ID
    >DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE
    >RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL
    >RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK
    >V NAME RVG KSTATE STATE LENGTH USETYPE PREFPLEX RDPOL
    >PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE
    >SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE
    >SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE
    >
    >
    >
    >
    >dg testdg default default 84000 970356463.1203.alu
    >
    >dm testdg01 c1t4d0s2 sliced 2179 8920560 -
    >dm testdg02 c1t6d0s2 sliced 2179 8920560 -
    >
    >v test - ENABLED ACTIVE 17840128 fsgen - SELECT
    >pl test-01 test ENABLED ACTIVE 17841120 CONCAT - RW
    >sd testdg01-01 test-01 testdg01 0 8920560 0 c1t4d0 ENA
    >sd testdg02-01 test-01 testdg02 0 8920560 8920560 c1t6d0 ENA
    >
    >
    >
    >--------------------
    >
    >OK, apart from the headers (printed with the"h" option), we see :
    >
    >
    >dm testdg01 c1t4d0s2 sliced 2179 8920560 -
    >dm testdg02 c1t6d0s2 sliced 2179 8920560 -
    >
    >(The header will show the columns
    >(DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE )
    >
    >OK, these are the disks in the Disk Group. We see their Volume Manager
    >names (testdg01 and testdg02), their real device names (c1t4d0 and
    >c1t6d0), which can change at any time (adding new controllers or new
    >disks or .....). We also see that the disks are sliced (explained above)


    >and that the private region is 2179 bytes big (normally the size of 1
    >cylinder on the disk) and the public area is 8920560 x 512 byte blocks big
    >
    >
    >
    >A line starting with "v" indicating the volume:
    >
    >(from the header
    >(V NAME RVG KSTATE STATE LENGTH USETYPE PREFPLEX RDPOL)
    >
    >
    >
    >v test - ENABLED ACTIVE 17840128 fsgen - SELECT
    >
    >
    >
    >We see the name is "test", the Volume is ENABLED ACTIVE , which means we


    >can read from it and write to it (if permissions allow) and we see the
    >size of the volume (17840128 blocks of 512 bytes). Lastly we see what
    >this volume will be used for. General Filesystems (fsgen).
    >
    >
    >OK, the next line gives us the plex. A plex = mirror. In this case we
    >have only one plex (one line starting with "pl". The plex line will also


    >give us the layout of the volume:
    >
    >(from the header: )
    >(PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE)
    >
    >
    >pl test-01 test ENABLED ACTIVE 17841120 CONCAT - RW
    >
    >
    >OK, so we see the plex name is "test-01" and it is part of higher object


    >(or volume) called "test". We see the plex is ENABLED ACTIVE, which
    >means this mirror is good (in some cases where you ahve more than 1 plex


    >or mirror, 1 might be good and the other bad - which you can recover).
    >We also see the size of the plex (17841120 x 512byte blocks). The plex
    >is a bit bigger than the volume due to rounding.
    >
    >
    >Next we see that the plex has data on 2 disks (or sub-disks). A sub-disk


    >is a logical part of the public area that can be addressed. This can be


    >as small as 1 x 512 byte block, and there are almost no limits to the
    >number of sub-disks that can be created on a single disk.
    >
    >So, let's look at the sub-disks on our 2 physical disks (we know we have


    >2 disks in the disk group)
    >
    >(From the header in vxprint
    >(SD NAME PLEX DISK DISKOFFS LENGTH COL/]OFF DEVICE MODE)
    >
    >
    >
    >sd testdg01-01 test-01 testdg01 0 8920560 0 c1t4d0 ENA
    >sd testdg02-01 test-01 testdg02 0 8920560 8920560 c1t6d0 ENA
    >
    >
    >
    >Sub-disk lines start with "sd" and then the name of the sub-disk. This
    >name can be changed, but generally the name will be the name of the disk


    > (as Volume Manager sees it) followed by a "-" followed by the number
    >of the subdisk (starting at 01, then 02, then 03 ,.......)
    >
    >So, we see that testdg01-01 is the first subdisk on the disk called
    >testdg01. We also see that this sub-disk forms patr of the higher order


    >object (in this case a plex) called "test-01" and we can see that this
    >sub-disk is part of the disk called "testdg01" (well, we know that
    >already). We also see teh diskoffset (or how far into the public region


    >this sub-disk starts) as well as the length of the sub-disk (8920560 x
    >512 byte blocks in our case).
    >
    >The next column can be used for counting columns (like in a stripe or in


    >a RAID 5), or will only tell us the offset into the plex (like what it
    >does in this case), where this sub-disk keeps the data for.
    >
    >
    >
    >OK, and you did not even know that you would get such a lot out of
    >vxprint. From the above we can see that the whole disk (for both the
    >disks) are used in sub-disks (see length of the disks in the "dm" line
    >and take away what has been used in all "sd" lines mentioning the disk).
    >
    >So, from our calculations, youcan see that the whole disk is used (for
    >both disks). This is what I mentioned, you can calculate the stuff
    >yourself if you want to. That is also why I said if you post a vxprint
    >here, I will do it for you or show you how it is done.
    >
    >
    >------
    >OK, having said all that, let's look at your output of vxdg free
    >
    >We see that in the diskgroup called rootdg, there is only 1 disk with
    >free space, and that is the disk called "rootd01" and this disk has some


    >space starting at offset 8388608 blocks into the public area and with
    >length of 9388462 x 512 byte blocks (no flags, means no reservations or


    >that it has been marked bad or anything like that).
    >
    >The same can be seen for a disk called "disk01" in a diskgroup called
    >"swdg".
    >
    >If you do not belive the output of vxdg free, please calculate for
    >yourself by adding the sizes of all the sub-disks on each disk and then


    >see if there is anything left from the size of the disk (all of which
    >can be seen in the vxprint outputs)
    >
    >By all means go ahead and do it !! You will only go through the
    >calculations once in your life to find that the vxdg free has been right


    >all along (or someone else would have reported it to Veritas ages ago,
    >this commands has been around since version 2.x)
    >
    >
    >
    >
    >
    >Sandip wrote:
    >> Hi Me,
    >>
    >> Thanks for your reply. I am just trying to understand how I can calculate
    >> disk spcae utilization from command line. Thanks for 512 byte block info.
    >> I used think it is 1024 byte block.
    >>
    >> Can you please help me to understand the following output.
    >>
    >> GROUP DISK DEVICE TAG OFFSET LENGTH

    FLAGS
    >> rootdg rootd01 c4t0d0 c4t0d0 8388608 9388462

    -
    >> swdg disk01 c4t7d0 c4t7d0 16824624 952446


    >> -
    >>
    >> In the above output I understand OFFSET means if I want to create any

    new
    >> volume then it would be that sector position. What about LENGTH ? Does

    that
    >> mean 952446/2 would be total bytes available.
    >>
    >> Thanks for your advise.
    >>
    >>
    >>
    >>
    >> Me wrote:
    >>
    >>>The size free is in number of 512 byte blocks.
    >>>
    >>>vxdg free shows only what is free.
    >>>
    >>>OK, so you don't believe what you saw ?
    >>>Just have to calculate a bit.
    >>>
    >>>do "vxprint -th"
    >>>
    >>>This will show you all the diskgroups and all the disks in that diskgroup.
    >>>
    >>>Let's take rootdg. It will show you how many disks youve got, the size


    >>>of the disks and then the volumes. Each volume will show you the
    >>>sub-disks (sd lines) where you can then go and calculate what is being


    >>>used on each disk.
    >>>
    >>>So, go ahead and do the maths and see if you come to the same conclusion

    >>
    >>
    >>>as vxdg free.
    >>>
    >>>If you don't know what I'm talking about, then post the output of
    >>>"vxprint -th" here and I will show you how to calculate.
    >>>
    >>>Sandip wrote:
    >>>
    >>>>Thanks,
    >>>>
    >>>>When I am giving vxdg free it is showing following output..
    >>>>
    >>>>root:> vxdg free


    >>
    >>
    >>>>>>
    >>>>
    >>>>
    >>>>Does that output means swdg disk c4t7d0 has only 950MB available ? What

    >>
    >> about
    >>
    >>>>other disk in swdg ? Do that mean that disk is 100% full.
    >>>>
    >>>>
    >>>>
    >>>>Me wrote:
    >>>>
    >>>>
    >>>>>vxdg free
    >>>>>
    >>>>>Sandip wrote:
    >>>>>
    >>>>>
    >>>>>>Dear All,
    >>>>>>
    >>>>>>Is there any way we can find disk utilization details from command

    line.
    >>>>>
    >>>>>>From VEA GUI we can see how much % disk space is being utilized but

    I
    >>>>
    >>>>am
    >>>>
    >>>>
    >>>>>>looking for any solution through command line.
    >>>>>>
    >>>>>>I tried with vxprint outout but it really difficult to calcute the

    same.
    >>>>>>
    >>>>>>
    >>>>
    >>>>

    >>



  8. Re: disk device utilization

    You're right.

    As you might have seen from the way I explain (prtvtoc), I explained
    Solaris (90% of Veritas products sold is on Solaris).

    HP-UX has a 1024 size to conform to the LVM (btw. LVM is nothing but
    Volume Manager 3.0 sold to HP-UX) standards (which work in 1024 byte
    blocks).



    Sandip wrote:
    > Me,
    >
    > Thanks a lot for your kind brief explanation. I really appreciate the same.
    > It gave me a great knowledge.
    >
    > We use all the Veritas products on our HP-UX boxes.
    >
    > I tried to do the following test where it seems it prints 1024 bytes block
    > rather than 512. Please pardon me for my ignorance I am just trying to understand
    > this layout my level best.
    >
    > root [/]: diskinfo /dev/rdsk/c5t0d4
    > SCSI describe of /dev/rdsk/c5t0d4:
    > vendor: HP
    > product id: OPEN-E
    > type: direct access
    > size: 14226480 Kbytes
    > bytes per sector: 512
    >
    > Now if I see vxprint output it seems it shows 1K block as per the dm tst01
    > output.
    >
    > root[/]: vxprint -g testdg -ht
    >
    > DG NAME NCONFIG NLOG MINORS GROUP-ID
    >
    > DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE
    >
    > RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL
    >
    > RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK
    >
    > V NAME RVG KSTATE STATE LENGTH READPOL PREFPLEX
    > UTYPE
    > PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID
    > MODE
    > SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE
    > MODE
    > SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM
    > MODE
    > DC NAME PARENTVOL LOGVOL
    >
    > SP NAME SNAPVOL DCO
    >
    >
    >
    > dg testdg default default 6013000 1143447102.1344.testserver
    >
    >
    >
    > dm tst01 c5t0d4 simple 1024 14223040 -
    >
    >
    > Now when I create any volume as like following.
    > root@pluto [/]: vxassist -g testdg make testvol 2G
    > root@pluto [/]: vxprint -g testdg -ht
    >
    > DG NAME NCONFIG NLOG MINORS GROUP-ID
    >
    > DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE
    >
    > RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL
    >
    > RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK
    >
    > V NAME RVG KSTATE STATE LENGTH READPOL PREFPLEX
    > UTYPE
    > PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID
    > MODE
    > SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE
    > MODE
    > SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM
    > MODE
    > DC NAME PARENTVOL LOGVOL
    >
    > SP NAME SNAPVOL DCO
    >
    >
    >
    > dg testdg default default 6013000 1143447102.1344.pluto
    >
    >
    >
    > dm tst01 c5t0d4 simple 1024 14223040 -
    >
    >
    >
    > v testvol - ENABLED ACTIVE 2097152 SELECT -
    > fsgen
    > pl testvol-01 testvol ENABLED ACTIVE 2097152 CONCAT -
    > RW
    > sd tst01-01 testvol-01 tst01 0 2097152 0 c5t0d4
    > ENA
    >
    > In the volume column it is showing 2097152 block which if I calcuclate 2097152/1024
    > then it seems it is showing current 2GB output.
    >
    > Could you please advise me again if I wrong.
    >
    >
    >
    > Me wrote:
    >
    >>OK, the 512 byte blocks, is what Volume Manager deals with. Whenever it

    >
    >
    >>does IO, it will do so in 512 byte blocks. So every 2 blocks, will give

    >
    >
    >>you 1K. The erst of the calculations work from there.
    >>
    >>Now, the offset.
    >>
    >>Every disk under Volume Manager control, needs to keep some "private"
    >>information. This is stuff like, which diskgroup do I belong to ? What
    >>is my name (like rootd01), and where do I fit into the different
    >>volumes. This information can not be kept where your data is kept (as
    >>mentioned it is "private" to Volume Manager.
    >>
    >>So, on each disk that Volume Manager controls, there is a "private"
    >>area. This could be on a slice (on Solaris do "prtvtoc" on the disk and

    >
    >
    >>look for the slice with a tag of "15". This slice keeps the private
    >>information.
    >>
    >>Normally on a sliced disk, the user data is kept in a seperate slice
    >>(called the public slice). This is indicated with a tag of "14" in the
    >>prtvtoc.
    >>
    >>The biggest issue is that not all disks are sliced (with slices). There

    >
    >
    >>a disks with only 1 slice (AIX people will know what I'm talking about
    >>now). There might also be good reasons why we would like to see a disk
    >>as "without slices" (on Solaris, if you look only at slice 2 - the whole

    >
    >
    >>disk). The reasons would be CDS (Common-platform Data Sharing), which
    >>allows you to take the (Volume Manager) Disk between different systems
    >>(thus between a AIX system and Solaris or even Linux), and Volume
    >>Manager will understand the (private) data on the disk.
    >>
    >>Where the we don't have slices, the public data (your data) and the
    >>Volume Manager data (the private data), can thus only be on the same
    >>slice. Thus, Volume Manager needs to keep track of this. It "defines"
    >>(in it's own configuration) an area where the public data begins. (This

    >
    >
    >>is fixed and can not be moved once the disk has been placed under Volume

    >
    >
    >>Manager control). The offset from then onwards, indicates the number of

    >
    >
    >>512 byte blocks into the public area.
    >>
    >>
    >>
    >>So, let's look at the output of vxprint again. Just an example:
    >>
    >>
    >>
    >># vxprint -ht -g testdg
    >>
    >>
    >>DG NAME NCONFIG NLOG MINORS GROUP-ID
    >>DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE
    >>RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL
    >>RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK
    >>V NAME RVG KSTATE STATE LENGTH USETYPE PREFPLEX RDPOL
    >>PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE
    >>SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE
    >>SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE
    >>
    >>
    >>
    >>
    >>dg testdg default default 84000 970356463.1203.alu
    >>
    >>dm testdg01 c1t4d0s2 sliced 2179 8920560 -
    >>dm testdg02 c1t6d0s2 sliced 2179 8920560 -
    >>
    >>v test - ENABLED ACTIVE 17840128 fsgen - SELECT
    >>pl test-01 test ENABLED ACTIVE 17841120 CONCAT - RW
    >>sd testdg01-01 test-01 testdg01 0 8920560 0 c1t4d0 ENA
    >>sd testdg02-01 test-01 testdg02 0 8920560 8920560 c1t6d0 ENA
    >>
    >>
    >>
    >>--------------------
    >>
    >>OK, apart from the headers (printed with the"h" option), we see :
    >>
    >>
    >>dm testdg01 c1t4d0s2 sliced 2179 8920560 -
    >>dm testdg02 c1t6d0s2 sliced 2179 8920560 -
    >>
    >>(The header will show the columns
    >>(DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE )
    >>
    >>OK, these are the disks in the Disk Group. We see their Volume Manager
    >>names (testdg01 and testdg02), their real device names (c1t4d0 and
    >>c1t6d0), which can change at any time (adding new controllers or new
    >>disks or .....). We also see that the disks are sliced (explained above)

    >
    >
    >>and that the private region is 2179 bytes big (normally the size of 1
    >>cylinder on the disk) and the public area is 8920560 x 512 byte blocks big
    >>
    >>
    >>
    >>A line starting with "v" indicating the volume:
    >>
    >>(from the header
    >>(V NAME RVG KSTATE STATE LENGTH USETYPE PREFPLEX RDPOL)
    >>
    >>
    >>
    >>v test - ENABLED ACTIVE 17840128 fsgen - SELECT
    >>
    >>
    >>
    >>We see the name is "test", the Volume is ENABLED ACTIVE , which means we

    >
    >
    >>can read from it and write to it (if permissions allow) and we see the
    >>size of the volume (17840128 blocks of 512 bytes). Lastly we see what
    >>this volume will be used for. General Filesystems (fsgen).
    >>
    >>
    >>OK, the next line gives us the plex. A plex = mirror. In this case we
    >>have only one plex (one line starting with "pl". The plex line will also

    >
    >
    >>give us the layout of the volume:
    >>
    >>(from the header: )
    >>(PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE)
    >>
    >>
    >>pl test-01 test ENABLED ACTIVE 17841120 CONCAT - RW
    >>
    >>
    >>OK, so we see the plex name is "test-01" and it is part of higher object

    >
    >
    >>(or volume) called "test". We see the plex is ENABLED ACTIVE, which
    >>means this mirror is good (in some cases where you ahve more than 1 plex

    >
    >
    >>or mirror, 1 might be good and the other bad - which you can recover).
    >>We also see the size of the plex (17841120 x 512byte blocks). The plex
    >>is a bit bigger than the volume due to rounding.
    >>
    >>
    >>Next we see that the plex has data on 2 disks (or sub-disks). A sub-disk

    >
    >
    >>is a logical part of the public area that can be addressed. This can be

    >
    >
    >>as small as 1 x 512 byte block, and there are almost no limits to the
    >>number of sub-disks that can be created on a single disk.
    >>
    >>So, let's look at the sub-disks on our 2 physical disks (we know we have

    >
    >
    >>2 disks in the disk group)
    >>
    >>(From the header in vxprint
    >>(SD NAME PLEX DISK DISKOFFS LENGTH COL/]OFF DEVICE MODE)
    >>
    >>
    >>
    >>sd testdg01-01 test-01 testdg01 0 8920560 0 c1t4d0 ENA
    >>sd testdg02-01 test-01 testdg02 0 8920560 8920560 c1t6d0 ENA
    >>
    >>
    >>
    >>Sub-disk lines start with "sd" and then the name of the sub-disk. This
    >>name can be changed, but generally the name will be the name of the disk

    >
    >
    >> (as Volume Manager sees it) followed by a "-" followed by the number
    >>of the subdisk (starting at 01, then 02, then 03 ,.......)
    >>
    >>So, we see that testdg01-01 is the first subdisk on the disk called
    >>testdg01. We also see that this sub-disk forms patr of the higher order

    >
    >
    >>object (in this case a plex) called "test-01" and we can see that this
    >>sub-disk is part of the disk called "testdg01" (well, we know that
    >>already). We also see teh diskoffset (or how far into the public region

    >
    >
    >>this sub-disk starts) as well as the length of the sub-disk (8920560 x
    >>512 byte blocks in our case).
    >>
    >>The next column can be used for counting columns (like in a stripe or in

    >
    >
    >>a RAID 5), or will only tell us the offset into the plex (like what it
    >>does in this case), where this sub-disk keeps the data for.
    >>
    >>
    >>
    >>OK, and you did not even know that you would get such a lot out of
    >>vxprint. From the above we can see that the whole disk (for both the
    >>disks) are used in sub-disks (see length of the disks in the "dm" line
    >>and take away what has been used in all "sd" lines mentioning the disk).
    >>
    >>So, from our calculations, youcan see that the whole disk is used (for
    >>both disks). This is what I mentioned, you can calculate the stuff
    >>yourself if you want to. That is also why I said if you post a vxprint
    >>here, I will do it for you or show you how it is done.
    >>
    >>
    >>------
    >>OK, having said all that, let's look at your output of vxdg free
    >>
    >>We see that in the diskgroup called rootdg, there is only 1 disk with
    >>free space, and that is the disk called "rootd01" and this disk has some

    >
    >
    >>space starting at offset 8388608 blocks into the public area and with
    >>length of 9388462 x 512 byte blocks (no flags, means no reservations or

    >
    >
    >>that it has been marked bad or anything like that).
    >>
    >>The same can be seen for a disk called "disk01" in a diskgroup called
    >>"swdg".
    >>
    >>If you do not belive the output of vxdg free, please calculate for
    >>yourself by adding the sizes of all the sub-disks on each disk and then

    >
    >
    >>see if there is anything left from the size of the disk (all of which
    >>can be seen in the vxprint outputs)
    >>
    >>By all means go ahead and do it !! You will only go through the
    >>calculations once in your life to find that the vxdg free has been right

    >
    >
    >>all along (or someone else would have reported it to Veritas ages ago,
    >>this commands has been around since version 2.x)
    >>
    >>
    >>
    >>
    >>
    >>Sandip wrote:
    >>
    >>>Hi Me,
    >>>
    >>>Thanks for your reply. I am just trying to understand how I can calculate
    >>>disk spcae utilization from command line. Thanks for 512 byte block info.
    >>>I used think it is 1024 byte block.
    >>>
    >>>Can you please help me to understand the following output.
    >>>
    >>>GROUP DISK DEVICE TAG OFFSET LENGTH

    >
    > FLAGS
    >
    >>>rootdg rootd01 c4t0d0 c4t0d0 8388608 9388462

    >
    > -
    >
    >>> swdg disk01 c4t7d0 c4t7d0 16824624 952446

    >
    >
    >
    >>>-
    >>>
    >>>In the above output I understand OFFSET means if I want to create any

    >
    > new
    >
    >>>volume then it would be that sector position. What about LENGTH ? Does

    >
    > that
    >
    >>>mean 952446/2 would be total bytes available.
    >>>
    >>>Thanks for your advise.
    >>>
    >>>
    >>>
    >>>
    >>>Me wrote:
    >>>
    >>>
    >>>>The size free is in number of 512 byte blocks.
    >>>>
    >>>>vxdg free shows only what is free.
    >>>>
    >>>>OK, so you don't believe what you saw ?
    >>>>Just have to calculate a bit.
    >>>>
    >>>>do "vxprint -th"
    >>>>
    >>>>This will show you all the diskgroups and all the disks in that diskgroup.
    >>>>
    >>>>Let's take rootdg. It will show you how many disks youve got, the size

    >
    >
    >>>>of the disks and then the volumes. Each volume will show you the
    >>>>sub-disks (sd lines) where you can then go and calculate what is being

    >
    >
    >>>>used on each disk.
    >>>>
    >>>>So, go ahead and do the maths and see if you come to the same conclusion
    >>>
    >>>
    >>>>as vxdg free.
    >>>>
    >>>>If you don't know what I'm talking about, then post the output of
    >>>>"vxprint -th" here and I will show you how to calculate.
    >>>>
    >>>>Sandip wrote:
    >>>>
    >>>>
    >>>>>Thanks,
    >>>>>
    >>>>>When I am giving vxdg free it is showing following output..
    >>>>>
    >>>>>root:> vxdg free

    >
    >
    >>>
    >>>>>>>
    >>>>>
    >>>>>
    >>>>>Does that output means swdg disk c4t7d0 has only 950MB available ? What
    >>>
    >>>about
    >>>
    >>>
    >>>>>other disk in swdg ? Do that mean that disk is 100% full.
    >>>>>
    >>>>>
    >>>>>
    >>>>>Me wrote:
    >>>>>
    >>>>>
    >>>>>
    >>>>>>vxdg free
    >>>>>>
    >>>>>>Sandip wrote:
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>>>Dear All,
    >>>>>>>
    >>>>>>>Is there any way we can find disk utilization details from command

    >
    > line.
    >
    >>>>>>>From VEA GUI we can see how much % disk space is being utilized but

    >
    > I
    >
    >>>>>am
    >>>>>
    >>>>>
    >>>>>
    >>>>>>>looking for any solution through command line.
    >>>>>>>
    >>>>>>>I tried with vxprint outout but it really difficult to calcute the

    >
    > same.
    >
    >>>>>>>
    >>>>>

    >


+ Reply to Thread