Seagate SNAFU sees Cisco servers primed for data loss

Cisco's dropped Seagate in the pooh for a mess that's seen some UCS servers released into the wild in configurations susceptible to data loss. The mistake was small and simple: as Cisco's Field Notice explains, “Cisco ships all of their hard drives from manufacturing with drive write cache disabled” because “If a drive on one …

[Nate Amsden]

bad controller

Seems like this is the fault of whatever disk controller cisco is using. I don't recall any real storage controller whether it is HP or Dell or even my old 3ware controllers that didn't have controller enforced drive write cache settings.

Maybe cisco ships with nothing more than bare bones controllers but that would be even more surprising to me.

[A Non e-mouse]

Re: bad controller

In the Cisco UCS servers I've played with, they just threw a lot of third party components in a box, put a "Cisco" sticker on the outside and add a nice fat margin to the price.

[Anonymous Coward]

Re: bad controller

And who doesnt?

[Anonymous Coward]

Re: bad controller

S3260 has LSI 3316 controllers. That's pretty standard I'd say.

[Spotswood]

I heard...

.....of this thing quite some time ago on controllers called 'battery backup'.....????

[John Geek]

Re: I heard...

battery backup (or on newer RAID controllers, flash backed writeback cache using supercaps) only protects the write cache in the RAID controller. we're talking about write cache on the DRIVES, whihc is something desktop drives often have in write-back mode, but server drivers should always be write-through.

[Anonymous South African Coward]

"Bother" siad Pooh as he lost a ton of pr0nz

[Pompous Git]

""Bother" siad Pooh as he lost a ton of pr0nz"

There ya go! I could have sworn I heard Pooh say: "Kanga, can I put my tiddlypom in your verywarmplace?"

[WolfFan]

You two are being very sick bastards.

That's my job, dammit.

[Pompous Git]

That's my job, dammit.

You're being paid for being a sick bastard? Tell me more! I'm intrigued...

[WolfFan]

Re: That's my job, dammit.

You could get a similar job... if you have, say, pix of Vlad and his pony and the real reason why Vlad took off his shirt. I'll say no more lest there be some polonium in my future.

[LesB]

Blame Tigger for bouncing the server

[Zola]

Why are Seagate being fingered for this? It's not their SNAFU!

This is 100% Cisco's fsck up because it was Cisco that assumed rather than erred on the side of caution/professionalism by configuring the drives on receipt from their supplier - or on boot up, fancy that! - with the correct parameters/characteristics required to reliably perform the job they will be doing.

There is absolutely nothing wrong with what Seagate did, or did not do!

(Not a Seagate shill, I just think Cisco are entirely at fault here)

[Anonymous Coward]

Re: Why are Seagate being fingered for this? It's not their SNAFU!

The whole point of OEM orders is to have them shipped TO SPECIFICATION. Cisco obviously does some sample testing for QA but they have to assume that orders are coming in built as specified. If it weren't so, additional steps would be required in the factory for which no workstation or process step exist. Or were eliminated/optimized due to Seagate promising to do it in their factory in order to streamline manufacturing.

Dude, this is industrial manufacturing and supply chain management 101. There is absolutely no way to have constant OEM component spec checks in the assembly process. At some point you have to assume that your (ISO certified) supplier is actually performing according to their ISO cert processes.

[Anonymous Coward]

Even if Cisco specified to disable write cache, this is AWFUL, SLOPPY engineering.

Apparently Cisco is still as storage-stupid as they were when they bought Whiptail, then re-named it Invicta and then had to flush it all down the drain when they realized it was hopelessly broken.

The on-disk DRAM write caches that exists on every HDD and SSD on the market have been there forever. There are literally dozens of ways that a BIOS, an OS or an application can (and indeed are meant to) control whether writes are being cached on disk or not. That Cisco's engineers would fail to ensure system-level checks to ensure that the write-cache is off when it is supposed to be off is ludicrous.

Hey Cisco product managers, I know a few dozen storage engineers who know this stuff cold and would never have let you goof this up. Maybe stop putting networking engineers in your server/storage business and hire some real talent?

I sure hope the team that did due diligence on Springpath knows more about storage than the ones who presided over the Whiptail and Atlantis fiascos...