Forum Discussion

tanislavm's avatar
tanislavm
Level 6
11 years ago

dg time

Hi, I like to verify what happens when an disk group is imported on an host.There will be an check of dirty region?Why if we have an dg with a large number of logical volumes of large size each,the imported time could be very long?Could it be 30 min or 1 hour?So the failover of an service who contains this dg could takes 30 min or 1 hour? thanks.
business continuity
Solaris
Storage Foundation
  • Gaurav_S's avatar
    Gaurav_S
    11 years ago

    Hi,

    When a DG is imported, it will do a check for all the private regions of the disks. For a successful import, diskgroup should have valid configuration copy on private region of disks. Not all the disk contains configuration, if diskgroup is having large number of disks, few of the disks will be marked with config enabled. You can see which disks contain config by running "vxdg list <dgname>" command .. for e.g

    # vxdg list mydg
    Group: mydg
    dgid: 962910960.1025.bass
    import-id: 0.1
    flags:
    version: 140
    local-activation: read-write
    alignment : 512 (bytes)
    ssb: on
    detach-policy: local
    copies: nconfig=default nlog=default
    config: seqno=0.1183 permlen=3448 free=3428 templen=12
    loglen=522
    config disk c0t10d0 copy 1 len=3448 state=clean online
    config disk c0t11d0 copy 1 len=3448 state=clean online
    log disk c0t10d0 copy 1 len=522
    log disk c0t11d0 copy 1 len=522

    Now coming to second part, Ideally even if diskgroup is having may disks & volumes, it shouldn't take like 30 mins or 1 hour to import. It should import like a normal diskgroup (delay in seconds can be expected). It is quite possible that starting of volumes in a dg may take time that too if a background sync is going on. This can be checked via vxtask list.

    Dirty Region Log (DRL) is associated with volumes & not with diskgroup.

     

    G

  • Gaurav_S's avatar
    Gaurav_S
    Moderator
    11 years ago

    Hi,

    When a DG is imported, it will do a check for all the private regions of the disks. For a successful import, diskgroup should have valid configuration copy on private region of disks. Not all the disk contains configuration, if diskgroup is having large number of disks, few of the disks will be marked with config enabled. You can see which disks contain config by running "vxdg list <dgname>" command .. for e.g

    # vxdg list mydg
    Group: mydg
    dgid: 962910960.1025.bass
    import-id: 0.1
    flags:
    version: 140
    local-activation: read-write
    alignment : 512 (bytes)
    ssb: on
    detach-policy: local
    copies: nconfig=default nlog=default
    config: seqno=0.1183 permlen=3448 free=3428 templen=12
    loglen=522
    config disk c0t10d0 copy 1 len=3448 state=clean online
    config disk c0t11d0 copy 1 len=3448 state=clean online
    log disk c0t10d0 copy 1 len=522
    log disk c0t11d0 copy 1 len=522

    Now coming to second part, Ideally even if diskgroup is having may disks & volumes, it shouldn't take like 30 mins or 1 hour to import. It should import like a normal diskgroup (delay in seconds can be expected). It is quite possible that starting of volumes in a dg may take time that too if a background sync is going on. This can be checked via vxtask list.

    Dirty Region Log (DRL) is associated with volumes & not with diskgroup.

     

    G