See
the table below for the maximum resize limits sizes:
The reason behind it is that each SAN LUN has head/cylinder/sector geometry. It is not an actual physical mapping to the underlying disks. It’s simply a SCSI protocol object. But it imposes limitation on maximum LUN resize. Geometry is chosen at initial LUN creation and cannot be changed. You can resize the LUN to the size, which is ~10 times bigger than the size at the time of creation.
To check the maximum size for particular LUN use the following commands:
> priv set diag
> lun geometry lun_path
> priv set
If you run into this issue, unfortunately you will need to create a new LUN, copy all the data using robocopy for example and make a cutover. Because such features as volume level SnapMirror or ndmpcopy will recreate the LUN’s geometry together with the data
|
LUN
Size
|
Maximum
Resize
|
|
<
50g
|
502g
|
|
51-100g
|
1004g
|
|
101-150g
|
1506g
|
|
151-200g
|
2008g
|
|
201-251g
|
2510g
|
|
252-301g
|
3012g
|
|
302-351g
|
3514g
|
|
352-401g
|
4016g
|
The reason behind it is that each SAN LUN has head/cylinder/sector geometry. It is not an actual physical mapping to the underlying disks. It’s simply a SCSI protocol object. But it imposes limitation on maximum LUN resize. Geometry is chosen at initial LUN creation and cannot be changed. You can resize the LUN to the size, which is ~10 times bigger than the size at the time of creation.
To check the maximum size for particular LUN use the following commands:
> priv set diag
> lun geometry lun_path
> priv set
If you run into this issue, unfortunately you will need to create a new LUN, copy all the data using robocopy for example and make a cutover. Because such features as volume level SnapMirror or ndmpcopy will recreate the LUN’s geometry together with the data
No comments:
Post a Comment