ONTAP Discussions

Clarification on ostype for lun create

KelseyS
442 Views

Looking for clarification on the windows options for lun create.

https://docs.netapp.com/us-en/ontap-cli-9121//lun-create.html

 

  • windows - the LUN will be used with a Master Boot Record (MBR) partition table on Microsoft Windows 2003 or earlier.

  • windows_2008 - the LUN will be used with Microsoft Windows 2008 or later.

  • windows_gpt - the LUN will be used with a GUID Partition Type (GPT) partition table on Microsoft Windows.

I'm building servers newer than 2003 so would never use the "windows" MBR option. But my new servers are GPT so do I select windows_2008 or windows_gpt? What's the difference between these ostype parameters?

 

I wish the "windows" type could be renamed to "windows_2003" so it's not misleading.

Kelsey S.
1 ACCEPTED SOLUTION

AlexDawson
344 Views

I literally read the source code a few years ago to clear this up for myself - If you're creating a new LUN in 9.8 or later, just use windows_2008.

 

There were some paddings in LUNs created prior to 9.8 for block offsets matching those header sizes to match NTFS block sizes to on-disk WAFL blocks.

 

Post 9.8, some of that logic changes and those offsets are no longer required or placed into the LUN files, but the three types are kept for mostly user compatibility reasons.

 

ONTAP NVMeOF Namespaces for example make no distinction between the three, and "lun create" on ASA only allows "windows" as a type, but it is effectively windows_2008 - https://docs.netapp.com/us-en/ontap-cli-9131//lun-create.html#parameters

View solution in original post

5 REPLIES 5

cedric_renauld
369 Views

Hello,

GPT, is more "moderne" partitionning system.

More exependable = 9.4 Zeta octet

Compliant with UEFI bios

Mare partition possible : 128 vs 4 MBR

Compliant wiht HyperV system

AlexDawson
345 Views

I literally read the source code a few years ago to clear this up for myself - If you're creating a new LUN in 9.8 or later, just use windows_2008.

 

There were some paddings in LUNs created prior to 9.8 for block offsets matching those header sizes to match NTFS block sizes to on-disk WAFL blocks.

 

Post 9.8, some of that logic changes and those offsets are no longer required or placed into the LUN files, but the three types are kept for mostly user compatibility reasons.

 

ONTAP NVMeOF Namespaces for example make no distinction between the three, and "lun create" on ASA only allows "windows" as a type, but it is effectively windows_2008 - https://docs.netapp.com/us-en/ontap-cli-9131//lun-create.html#parameters

KelseyS
311 Views

Thanks for this! The explanations for the "windows" and "windows_2008" are clear, but "windows_gpt" is not so I would like to know more. Any example scenarios for when "windows_gpt" type would ever be used?

 

I also read around the net that "windows_gpt" only does GPT while "windows_2008" allows the OS to do either MBR or GPT partitioning on the lun, but I couldn't find this information consistently nor on the NetApp side. Do you know if this is true?

Kelsey S.

AlexDawson
276 Views

The different LUN types in ONTAP have been added over the years to enable the most efficient and performant storage given ONTAP and host OS requirements. Some of them expose different SCSI command primatives, and some were implemented to ensure block alignment between WAFL and the host OS. For Windows ones, it's all the latter reason.

 

  • "windows" is the original one, assuming an MBR partition and (eventually) adding ONTAP/wafl padding before the LUN to ensure the MBR ends at a WAFL block boundary
  • "windows_gpt" was added in ONTAP 7.2.1 in approx 2006, when Windows Server 2003 started supporting GPT partitioning, to ensure alignment given the bigger partitioning information headers, so it gets a smaller WAFL header
  • "windows_2008" comes about when Server 2008 tries to fix this problem by having an offset between headers and data blocks instead, so it gets a new type, since there's now a host level suffix to the header, instead of needing a storage level prefix.

As I say - they are now all functionally equivalent for a bunch of reasons, as ONTAP doesn't just store the prefix bytes in the WAFL blocks, it's almost 2025 and no one is using server 2003 (please..), and if you care about performance you're using SSD, and ONTAP now stores information about how the blocks are read and written and block offsets are less of a big deal. They're retained for compatibility reasons.

 

So hopefully this explains my original advice - just use windows_2008 now, as it tells ONTAP that it doesn't need to deliberately monkey with the geometry of the first block of a LUN. 

KelseyS
243 Views

This is perfect, thank you! Any chance we can get more descriptive information on the NetApp documentation? This is exactly the sort of information I was looking for but couldn't find.

Kelsey S.
Public