Thanks for the reply André.

Another, higher maintentance alternative, would be to continue to use thick disks, but then more routinely expand the disk, e.g. by 1GB, as required. It presumably means you'd have to have the partition you'd want to expand at the end of the disk (or at least without having to do a lot of faffing around).

I did read the post you suggested, though the block size debate didn't really relate to contiguous vs fragmented storage as far as I could tell. Satyam Vaghani's comment did make me start wondering though if setting the growth increment hasn't yet been implemented in such a mature product, does this mean it has no benefit (for some other subtle reason)?

Simon

Very interesting - you had exactly the same thought a year ago

Maybe for smaller OS files there wouldn't be much benefit, but for larger files, like database ones, there might be, especially where sequential access is concerned. What worries me is the layering - fragments at the OS level on top of fragments at the VMDK/VM level, fragment alignment etc. Trying to fathom out what's going on under heavy load would be very difficult indeed.

I suppose for bigger systems people carve up storage on the SAN into suitable LUNs and then pass the whole device through to the VM - this then means the VMFS question is irrelevant. Perhaps that's why there's not much interest.

I am wondering about the 8MB block size for datastores though - it's hard to see any downside (except for log and config files wasting a bit of space, though that could be managed with a different datastore if you could be bothered).

Simon

Anyone who's read this post and is thinking about vmdk mapping to LUNs, if they've not already seen them, might also be interested in these articles by Duncan Epping: http://www.yellow-bricks.com/2010/04/08/aligning-your-vms-virtual-harddisks/ and Vaughn Stewart (NetApp): http://blogs.netapp.com/virtualstorageguy/2010/04/raising-awareness-around-the-misalignment-of-data.html