HSBC and its customers were hammered last week after its core banking system computer in its Amherst data center failed because a corrupted disk caused systemwide problems.

I'm just hoping to see the explanation for that show up.

"Well, you see, RAID 6 is just too high for us, so we used RAID 0 for our critical data..."

 Or what?

bstorer:

You misunderstand. It wasn't that the data on the disk was corrupted, the disk itself was corrupted. It started wiping databases and shutting down systems because it had sold a bunch of HSBC's stock short. It's not uncommon for a disk to turn evil, that hard drive study Google did found that approximately 0.4% of disks turn evil, though the percentage leaps up to a staggering 7.2% if your data center is built on an ancient Indian burial ground.

This is why you are the best. 

bstorer:

You misunderstand. It wasn't that the data on the disk was corrupted, the disk itself was corrupted. It started wiping databases and shutting down systems because it had sold a bunch of HSBC's stock short. It's not uncommon for a disk to turn evil, that hard drive study Google did found that approximately 0.4% of disks turn evil, though the percentage leaps up to a staggering 7.2% if your data center is built on an ancient Indian burial ground.

This is the real reason SCSI is a problem.

IDE manufacturers knew this problem long ago; that's why they made sure their devices were always Intelligent enough to never issue commands. Issuing commands to other devices is a slippery slope; once a device starts doing it, it's just a matter of time before they think they can issue any command to any device.

And, of course, throw in the mix standard bank security, which assumes that any external signal is a threat, until such time as it is analyzed and determined legit - but internal signals, such as commands issued from a rogue SCSI device, are all considered trustworthy.

Interesting SCSI fact: if your data center is built on an ancient Indian burial ground, you can install SCSI equipment and have it just work, without any goat sacrifice. Because of this, SCSI devices are nearly 10 times more common in data centers built on Indian burial grounds. (That is, any SCSI experimentation will be successful, so people are likely to actually use it.)

(Don't get me wrong: needing to sacrifice anything to get a hard drive to work is problematic itself. But, the ends justify the means, and so for many people, SCSI seems like a good trade-off. If only they knew about the lurking danger...)

Fister:

HSBC and its customers were hammered last week after its core banking system computer in its Amherst data center failed because a corrupted disk caused systemwide problems.

I suppose if you had lots of money, or were the CEO, you'd certainly turn to the drink if you that happened.

bstorer and shepd made the jokes first!

Damn you both!

Are you actually suggesting that RAID protects against data corruption, or were you just mocking the bank for hypothetically thinking it?

tgape:

bstorer:

You misunderstand. It wasn't that the data on the disk was corrupted, the disk itself was corrupted. It started wiping databases and shutting down systems because it had sold a bunch of HSBC's stock short. It's not uncommon for a disk to turn evil, that hard drive study Google did found that approximately 0.4% of disks turn evil, though the percentage leaps up to a staggering 7.2% if your data center is built on an ancient Indian burial ground.

This is the real reason SCSI is a problem.

IDE manufacturers knew this problem long ago; that's why they made sure their devices were always Intelligent enough to never issue commands. Issuing commands to other devices is a slippery slope; once a device starts doing it, it's just a matter of time before they think they can issue any command to any device.

And, of course, throw in the mix standard bank security, which assumes that any external signal is a threat, until such time as it is analyzed and determined legit - but internal signals, such as commands issued from a rogue SCSI device, are all considered trustworthy.

Interesting SCSI fact: if your data center is built on an ancient Indian burial ground, you can install SCSI equipment and have it just work, without any goat sacrifice. Because of this, SCSI devices are nearly 10 times more common in data centers built on Indian burial grounds. (That is, any SCSI experimentation will be successful, so people are likely to actually use it.)

(Don't get me wrong: needing to sacrifice anything to get a hard drive to work is problematic itself. But, the ends justify the means, and so for many people, SCSI seems like a good trade-off. If only they knew about the lurking danger...)

also lets not forget the benefit of having a giant pentagram painted on the floor of your server room.  As well as symbols from the necronomicon carefully arranged on the hardware itself.  This way IT won't need to monitor those systems as they will be controlled mainly by demons.  Course one must take great care not to scratch a section off the pentagram so as to maintain control over the demons 

The statement from HSBC was "corrupted disk" not "corrupted data."

RAID 5 and RAID 6 explicitly protect against data loss because of a corrupted disk (or, for RAID 6, two corrupted disks).

Let me re-phrase that. If you don't know which disk has been corrupted, then with RAID 5, you're screwed, but with RAID 6, you can still recover the data and prove which disk got corrupted.

And if disks can get evil, modren SATA(N) disks can get even more! And consider also that "SAS" does actually mean "SATANIC ALCHEMIC SCSI".

 Computers themselves are inherently evil, I feel dirty just typing this.....