Skip to main content
NetApp Knowledgebase

What is the maximum size to which a LUN can be resized?

Last Updated:

Applies to

  • SAN 
  • FlexPod 
  • Data ONTAP 7 and earlier 


  • How large can a LUN be grown?
  • How to determine the 10x limit of a LUN?
  • How large can an existing LUN be expanded?

LUNs are special files in Data ONTAP which are exposed as SCSI disks using block access protocols. These files can be resized under normal conditions up to 10 times their original size in ONTAP versions prior to 9.5, with a minimum resize upper limit of 64 GB due to their SCSI disk geometry attributes (also known as CHS, or Cylder-Head-Sector, data). The 64 GB minimum upper limit is based on 1 MB cylinder size and the maximum cylinder count of 65535 (the upper limit of a 16 bit value). This means that regardless of how small the LUN starts out as, you can always expand it to at least 64 GB.

Do not resize a solaris LUN type (BUG 834382).
(Possible error seen when resizing a solaris LUN - "Error: command failed: Function not implemented" )

The lun geometry command was added in Data ONTAP 7.0 to view and edit the disk geometry attributes of a LUN. When used with a LUN path, the command will display the LUN geometry as well as the maximum size the LUN is able to be resized to. It is only available in elevated privilege modes advanced and diag:

*** Data ONTAP 8 uses <priv set diag> 

 filer> priv set diag
 filer> lun geometry /vol/vol1/my_lun
 SCSI Disk Geometry:
 512 bytes/sector
 256 sectors/track
 16 tracks/cylinder (heads)
 4096 sectors/cylinder
 5120 cylinders
 20971520 sectors
 2097152 cylinder size (2megabyte (MB))
 10737418240 device size (10240 MB)
 137436856320 max resize size (131070 MB)

Note: The last line of this output (max resize size) will denote how large a LUN might be ultimately grown to.

When Data ONTAP creates a LUN, it calculates what the SCSI geometry will be if the LUN is grown to 10x the initial creation size.

This will determine how large a LUN can be grown to - nominally 10x its original size in ONTAP versions prior to 9.5. Again, this is true for LUNs larger than 6 GB. Any LUN created smaller than 6 GB will be allowed to grow to 64 GB due to its geometry, referring back to the 1 MB cylinder size with 65535 cylinders.

Note: Because Windows LUNs have much larger cylinder sizes, they can be resized to large sizes. LUNs that are <= 50GB can all be resized to approximately 500GB.

How to increase the size of a LUN beyond its 10x limit regardless of starting size (7-Mode):

Perform the following action plan to manually increase the size of a LUN beyond the original 10x limit, even if the original LUN is smaller than 6GB:

Warning: Do not increase the cylinder_size above the 271,434,240 value given in the below example. Do not perform this action for Solaris type LUNs.

  1. Take a Snapshot of the volume which contains the LUN. This can be used as the basis for a fail back plan, if the resultant resize of the LUN does not produce expected results for any reason.
  2. Change the cylinder size by running the lun attribute command. This will trigger a re-computation of sectors per track and number of cylinders in the LUN geometry data:
    lun attribute set -f /vol/vol1/my_lun cylinder_size 271434240
  3. Confirm that the geometry was changed by running the lun geometry command and the new maximum LUN size is reported as 16 TB (16742279 MB, the maximum LUN size in Data ONTAP).
    You should now be able to resize the LUN using normal means to the new size (up to the 16 TB maximum).
  4. After resizing the LUN, rescan the LUN from your SAN host operating system to view the new size.
  5. At this point, refer the host operating system or other third-party documentation on managing partitions, volumes, and file systems within the LUN.

How to increase the size of a LUN beyond its 10x limit regardless of starting size (Cluster-mode):
In ONTAP 9.5, the 10x resize limit was removed, therefore normal resizing methods are avaialble. In Clustered Data ONTAP 8.x and ONTAP 9 versions prior to 9.5, this capability is not present. Instead, a new volume and LUN should be created, and the data migrated to the new (appropriately sized) location. You can leverage copy offload on supported platforms to improve system utilization during migration to the new LUN. Copy offload might also negate space utilization for data copied to the new LUN if it is created in the same volume and the copy offload engine is able to leverage the space efficiency engine for sub-LUN block cloning. (BUG  692842)


Additional Information