<   Previous Post  SVC Questions &...
Innovation, inventio...  Next Post:   >

Comments (4)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 localhost commented Trackback

Dude!I didn't say anything. Not a thing. Or at least I didn't yet.<div>&nbsp;</div> And when you call me Mark at least one EVP and a phalanx of VPs think you're speaking to them! That's why I'm considering legally changing my name to Mr Idontcachedatabutyoudo<div>&nbsp;</div> What do you think. ;)

2 localhost commented Trackback

Not sure if any of the Hitachi folks have noticed your existence yet. HHSNBN tends not to link or engage outside of his own blog anyway.<div>&nbsp;</div> So I'll jump in and confirm that Hitachi does indeed regenerate the I/O requests, just like the SVC. New to the USPV implementation is a "fast path" that bypasses writing to cache for similar "practically nonexistent additional latency." But I don't think the USPV can fast-path conditionally - you either run through cache or you don't. And if you don't run through cache, you sacrifice the ability to do local or remote mirroring (since that requires a cached copy of the data) - you can't have your cake and eat it too!<div>&nbsp;</div> Fact is, as I'm sure you will uncover, the Hitachi virtualization is more suited for migrating data into the array ("vampire" mode), or for storing backups out on cheep external storage...continuous I/O redirection (like Invista and SVC) not so much. In fact, it pretty much says exactly that in the Hitachi and HP documentation.<div>&nbsp;</div> Or so I've been told ;)

3 localhost commented Permalink

PMSL @ Mr IDCDBYD <div>&nbsp;</div> BarryB, thanks for the confirmation. Figured it was probably like that. Must see if I can find that documentation you refer to... would be very useful to have that from the horses mouth so to speak.

4 localhost commented Trackback

Easiest way to get the documentation is to simply purcahse a USP-V of your very own!