On Wed, Feb 8, 2012 at 2:56 PM, Kurt Buff <[email protected]> wrote: > There may be a workaround, by chaining together some LUNs (perhaps in > Windows, too), but that seems like a fugly hack to me.
Hmmm, that's interesting. If the problem is that their iSCSI implementation is written for the SCSI-2 command set, then aggregating LUNs *in the device* wouldn't help. You'd still be stuck with a 32-bit LBA, as far as I know. (Appending LUNs in Windows would be a different story.) As far as "ugly hack"... if this was a legitimate limitation, I'd say aggregating LUNs would be an appropriate solution. If a single disk isn't big enough, we aggregate multiple disks (and call it "RAID"). Using the same strategy for a limitation at the SCSI protocol level that does not exist at a higher level of the OS is a very legitimate approach. That said, I suspect this is a purely artificial limitation. As noted, SCSI-2 is twenty years old. I believe SBC-1 introduced 64-bit LBAs, and that was released in 1997 -- fifteen years ago. The iSCSI specification appears to be RFC-3720, which wasn't published until 2004. There's no way EMC was unaware of this. >>> it's truly a bad decision to hold back on it for market differentiation. >> >> Your company bought it anyway, so maybe not. > > And I'm bitching about it on a list that is widely read, and where I > have a modicum of respect afforded my opinions, so I'll hold fast to > my thought on that... We can hope. In my experience, PHB trumps BOFH every time, but we can hope. "Even the losers get lucky sometimes."[1] -- Ben [1] This statement is intended to be inclusive of the author. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
