Effective December 3, NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources.For accounts that did not pre-register (prior to Dec 3), access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity.To learn more, read the FAQ and watch the video.Need assistance? Complete this form and select “Registration Issue” as the Feedback Category.
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.
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.