https://slotsdad.com/ - casino online slots

Chasing a Boogeyman?

by Administrator on August 20, 2012

For awhile now, I have been advancing the line that VMware introduced 9 primitives in the form of VAAI that were proprietary and unapproved by the regulatory body overseeing SCSI:  ANSI T-10.  A couple of weeks ago, I received a post from someone who said that I was mistaken.  While the original version of VAAI might have been introduced before the commands/primitives were approved by ANSI, VMware has since been doing its due diligence to avoid messing up SCSI with proprietary verbs and nouns.

Here is the comment…

signal_lost July 26, 2012 at 1:35 am

http://blogs.vmware.com/vsphere/2011/10/vmware-is-contributing-to-t10-standards.html

To back up what they are talking about…
ftp://ftp.t10.org/t10/document.05/05-270r0.pdf
ftp://ftp.t10.org/t10/document.08/08-356r4.pdf

VMware has made these commands standard T10 commands (well I think the Write Same command that Symantec’s volume manager been using forever was already one). I think I saw HDS documentation related to this in terms of their thin provisioning reclaim like 3-4 years ago. These commands are not honestly the evil you set them out to be (XCOPY i’m pretty sure

I will agree with you that they introduced them in 4.1 without being actually aproved SCSI Commands and at the time were technically vendor only exntesion,s however in reality what they did was pull a Cisco and ship something that was in draft spec. As of vSphere 5 this stuff is all T10 commands as far as I’m aware.

I’d argue the T10 committee is grossly underfunded, and a vendor at least adopting 3 year old proposals and making them work and forcing testing isn’t really that bad of a thing. (Seriously, the T10 committee is thanking HP for an HP G3 according to their website, if they are really that broke I can offer them hardware/ hosting for free).

The fact that T10 approved SCSI write same UNMAP and somehow all major vendors implemented it (well except HDS who said it was a bad idea) without proper testing (and the performance across every vendor with it running is atrocious, I’ve seen 75% IO impact on flagship arrays) shows a complete lack of due diligence in the committee and its members if you ask me…

I mean no disrespect to the reader whatsoever, and appreciate the links.  However, even these links do not seem to offer much to change my view.

Let’s work up from the bottom.  Yes, T10 is underfunded and underserved by the vendor community both in terms of financial support, testing support and intellectual capital.  Alas, this has always been the case with standards groups, but I do not want to even think about a world with no open standards.

Yes, good testing and validation could improve implementation and long lag times in getting such testing done is a hassle.  That doesn’t validate VMware’s end runs around T10, which has led to development of its own certification queues, and caused many rig vendors pain in getting their products “certified” as VAAI compliant.      Moreover, we should keep in mind that VAAI is intended to fix problems that were CREATED BY VMware:  to alleviate 20% of the I/O workload that they have jammed up inside their stack.  They are not seeking to advance a generalized improvement in SCSI efficiency, but to fix problems of their own design, aren’t they?

Finally, the two PDF links provided cover, I believe, only one of the nine primitives comprising VAAI.  Are the others also submitted for review by ANSI?  What is the current status?  The post from the VMware blogger has more spin than fact on this point.

In the final analysis, I wonder if proprietary implementations of SCSI commands doesn’t set the stage for a need to segregate storage that works behind VMware kits from storage serving other hypervisor stacks or physical server workload?  That is the big issue:  we have gone through 10 years aggregating storage.  Do we now allow a hypervisor vendor to tell us to segregate it again?  That’s something I find rather aggravating.

I suspect some others do too.

{ 3 comments… read them below or add one }

signal_lost August 21, 2012 at 8:21 pm

The Block Zero Thin Provisioning VAAI for Thin Provisioning is just an abuse of the Write Same command to use in conjunction with array zero page reclaim is actually an existing SCSI command (Think Verita’s Volume Manager used that for quite a while back as HDS supported it for Thin reclaim before VAAI existed). This is rather valuable as it can be used to accelerated zero writing on arrays like Datacore for reclaim.

2. SCSI UNMAP is just using a previously reserved bit on write same. Its a modification that I think dates back to 2009. This command isn’t something I’d blame on VMware but array vendor’s who didn’t have an elegant way to reclaim space in place (Netapp, EMC, EqualLogic etc).

Atomic Test and SET early drafts date back to Feb.of 2009
I’ll concede your point here. This clearly solves a problem for x86 virtualization users (which are arguably the largest users of clustered file system’s that need granular locking within LUNs). It will benefit others though and is worthy of being ratified.

Extended Copy (XCOPY) I found references to it dating back to 1999
http://www.t10.org/ftp/t10/document.99/99-143r1.pdf
This solves a problem of people wanting to move large amounts of data within LUNs around and not being able to leverage LUN copy operations. This was fine back when disks where small, but as disks have increased in size faster than storage fabrics this is becoming a bigger thing. Microsoft will support this for Server 2012 from my understanding.

TP-STUN isn’t really anything radical that impacts IO, its just automating some basic behavior based on an array running out of space (Something that shouldn’t happen if your doing Thin Provisioning right, and was likely something thrown in because EMC Chuck is convinced that people don’t pay attention to their arrays…
A SCSI command I guess is a mildly easier out of band way to do this, but this is nothing that a few lines of vCLI and my SNMP monitoring of my storage pools couldn’t have done anyways….

I did some further digging to find source dates.
Revision 0 of write same actually dates back to what 2008, but I think the origin of this predates them. (I know I’ve seen references to it in HDS target configurations that predate that).

Given that Microsoft and Linux have supported these extensions (EXT4 supports UNMAP) I’m not hugely worried about them fragmenting the storage market…

signal_lost August 21, 2012 at 8:30 pm

Also next time your in Texas lets grab drinks again.

signal_lost August 21, 2012 at 8:33 pm

For the record If anyone deserves to be roasted for implementing pre-draft standards its Cisco. These guys invented it.

On the topic of standardization Steve) has got a great argument about what standardization really means. http://blog.fosketts.net/2011/12/15/myths-standardization/

Previous post:

Next post: