Confused about desired LUN size vs actual LUN size

[BOIWABOIWA]

Hey there,

I'm net to NetApp storage, and I'm quite confused about the size of the LUNs I'm creating. Have a look at those commands:

my-cluster::lun> create -volume my_volume -lun test_lun_1 -size 1099511627776 -ostype windows_2008

Created a LUN of size 1t (1099604782080)

my-cluster::lun> create -volume my_volume -lun test_lun_2 -size 2199023255552 -ostype windows_2008

Created a LUN of size 2t (2198888778240)

my-cluster::lun> create -volume my_volume -lun test_lun_3 -size 3298534883328 -ostype windows_2008

Created a LUN of size 3t (3298740318720)

Here I'm creating three LUNs, with 1 TiB, 2 TiB and 3 TiB. I supplied the size in bytes just to make my problem a bit clearer, the result is the same when I use "1t", "2t" and "3t".

If you look closely you'll notice that the size of the created LUN is actually not the same size as I wanted them to be. The 1 TiB and 3 TiB LUNs are slightly bigger, while the 2 TiB LUN is smaller than the desired size. This seems to mostly happen when using any of the Windows OS types, VMware and Linux don't have this problem most of the time.

Can anybody explain this behaviour to me? I assumed it's some file system block size thing, but that doesn't explain why the 2 TiB LUN is smaller than 2 TiB.

[JGPSHNTAP]

There's a fundamental size difference between TiB and TB.  One is done base 2, one is done base 10.   TiB = Tebabyte., TB = Terabtye.  So, which one do you want?

And I always prefer createing in the value we want to see, hence 2t, or 3t  not in bytes..

[BOIWABOIWA]

Yeah, I know the difference between TiB and TB. As I said it doesn't make a difference if I enter 1 TiB as the exact number of bytes, or as "1t", the result ist the same.

[aborzenkov · Accepted solution]

For legacy reasons NetApp fakes CHS geometry for a LUN, so full size will always be multiple of cylinder size. Exact geometry depends on os type for the same legacy reasons.

[BOIWABOIWA]

Thanks, that makes it more clear. After some googling I found the lun geometry command, which produces this output:

my-cluster::lun*> geometry

        Vserver Name: vserver-1

                Path: /vol/my_volume/test_lun_1

    Bytes per Sector: 512

   Sectors per Track: 1323

Tracks per Cylinder: 255

Sectors per Cylinder: 337365

Number of Cylinders: 6366

     Max Resize Size: 11319918220800

   Number of Sectors: 2147665590

       Cylinder Size: 172730880

         Device Size: 1099604782080

        Vserver Name: vserver-1

                Path: /vol/my_volume/test_lun_2

    Bytes per Sector: 512

   Sectors per Track: 2079

Tracks per Cylinder: 255

Sectors per Cylinder: 530145

Number of Cylinders: 8101

     Max Resize Size: 17555552340480

   Number of Sectors: 4294704645

       Cylinder Size: 271434240

         Device Size: 2198888778240

        Vserver Name: vserver-1

                Path: /vol/my_volume/test_lun_3

    Bytes per Sector: 512

   Sectors per Track: 2079

Tracks per Cylinder: 255

Sectors per Cylinder: 530145

Number of Cylinders: 12153

     Max Resize Size: 17555552340480

   Number of Sectors: 6442852185

       Cylinder Size: 271434240

         Device Size: 3298740318720

3 entries were displayed.

I didn't find any documentation of how number of sectors per track, tracks per cylinder etc. are determined. Does anybody know of a documentation like  that?

[aborzenkov]

There are a couple of KB articles - I’ll leave the fun to search for them to whoever is interested ☺. From experience, when you create LUN DOT tries to compute number of cylinders approximately 1/10th of maximum value (64k). This is because number of cylinders is the only parameter that can be safely increased after initial creation (yes, there still exist operating systems that base disk partitioning on CHS values …). That is exactly the reason for proverbial “you can only increase LUN size to 10 fold of original size”. And then computes other values (tracks per cylinder and sectors per track) to fit resulting size.