Extents and VMFS volumes

Ran across this article and it is a good read filling in a lot of info a vmware engineer should know.
http://blogs.vmware.com/vsphere/2012/02/vmfs-extents-are-they-bad-or-simply-misunderstood.html
Thanks to  Cormac Hogan for an informative article!
I'm taking the snippits of the article as a short preview for the highlights of information that I think are important.




Describe what  an extent is
1. A VMFS volume resides on one or more extents.
2. Each extent is backed by a partition on a physical device, such as a LUN.
3. Normally there will be only one extent for each LUN
4. more extents can added if you want to expand the volume.




Example using extents
5. The maximum size of a single VMFS-3 extent was 2TB.
6. Adding additional extents to a VMFS-3 volume was the only way to extend it above 2TB.
7. Adding 32 extents/LUNs to the same VMFS-3 volume gave you a maximum size of 64TB
8. VMFS-5 volume can be as large as 64TB on a single extent.
So by adding extents to the VMFS-3 volume, the VMFS volume could grow larger than 2TB




Extents are not like [RAID] stripes.
9. The hosts try to put distance between themselves on the datastore to reduce any contention for resources, but they still try to keep the objects that they manage close together.
That is why they might appear to be striped. But it's not striping the objects among different extents for raid abilities just avoiding contention
10. in a multi-extent situation, concurrent hosts accessing a VMFS volume will naturally spread themselves out across all extents


11.  Because of [] contiguous allocation of space (which can be in the order of 100MBs or even GB), VMFS does not suffer from the traditional fragmentation issues seen on other filesystems.


Losing one extent will offline the whole volume
12. Not completely true
13. if the head extent (1st member) has a failure, then it can bring the whole datastore offline. Head extent offline condition is pretty much always going to cause failures because many of the address resolution resources are on the head extent.
14. if a non-head extent member goes down, you won't be able to access the VMs whose virtual disks have at least 1 block on that extent. 


Misconception- Its easy to mistakenly overwrite extents in vCenter
15. t this was resolved in version 2.x,
16. occurred when you built an extent on one host, and then flipped onto a view from another ESXi host which didn't know that the LUN was now in use.
17. any changes made to a datastore, where a LUN is added as an extent, updates all the inventory objects so that this LUN is removed from the available disks pool.
18. f you decide to start working outside of vCenter and decide to work directly on the ESXi hosts, you could still run into this issue.


You get better performance from extents
19. some merit to this.
20. You could indeed make use of the per device queue depth to get an aggregate queue depth for all extents.
21. only relevant if a larger queue depth will improve performance, which may not always be the case.
22. benefit from the aggregate queue depth, each of the extents/LUNs that makes up the volume may have to be placed on different paths




VMware's Best Practice/Recommendation for Extents
23. recommendation would be to avoid the use of extents unless you absolutely have to use them.
24. the only cases I can see where you might need extents are:
• You are still on VMFS-3 and need a datastore larger than 2TB.
• You have storage devices which cannot be grown at the back-end, but you need a datastore larger than 2TB.




Final Thoughts:
25. nothing inherently wrong with extents, but the complexity involved in managing them has given them a bad name.




Avoid if possible