A little history, courtesy of TechNet. To help you wrap your head around it, Snakefoot has this to say. Ubernerds, anyone? The more things change, the more they stay the same.
Failed writes of cached writes is indeed a cause of corrupted or lost data.
Thanks for including this link: Write Back Cache Experiments
That was a nice read and very informative. :) But VERY dated being written/done in 2003. In the 90s and even up to early 21st century, write-back caching was frowned upon because the controller chip technology wasn't nearly as advanced as it is today. Also, they're using EXT3 and other Linux file allocation methods and older ATA (IDE) drives, not NTFS or anything on the Windows side with newer SATA drives.
Let's not confuse write-back caching with disabling the write buffer flushing which is what that "advanced" mode or last checkmark box in Windows 7 is about. The two are a little different.
Yes, it is possible to lose and corrupt data with write-back caching enabled, but it's also possible to lose and corrupt data if your HDD or SSD is writing when it loses power, regardless of its cache state or operational mode. There is hardly any additional risk in using write-back caching these days (it is nominal).
In fact, for larger files, write-back caching will speed up writing and reading to/from a disk, lessening the risk. In smaller files, the overhead for working with the buffer is greater, and therefore it takes roughly the same time. With lots of reads and writes being queued up in the buffer (ie: when an application is loading and a log is being written), then having write-back caching is a little more risk.
Write-back itself means the data is flagged as being written to the drive even if it's still in the cache. But the cache is often flushed regularly and very quickly when the read/write demmand on the drive or drive array is low. There is actually a lower risk of data corruption (file partially written before a power loss or crash) with write-back caching because the write from a buffer occurs faster than a write-through transaction. But there is a higher risk of data loss (losing a files completely due to a power loss or crash).
If we Google it, you'll find advocates for both enabling it and disabling it. I only enable it when I'm gaming (reading files more than writing them) and disable it when I'm doing any real work. But regardless, the risk of data corruption and loss is there regardless of whether you enable it or not.
Either way, I always run on a UPS, but an O/S can still crash hard and lose data.
As was your post. In fact, of all the isolated banter in these threads, this is my favorite. Not because of it's subject matter, but because of it's form and content. If only we were all sitting about the conference room and learning together.
There is little if anything outdated in computer science. Babbage's work in mechanical computing will soon come full circle. See Kruglick, E.J.J.: Microrelay design, performance, and systems
There is quite a bit of truth in that statement. Principles remain the same even if their application evolves. And even future technology is based on past principles: things are still governed by them same set of physics (even if we don't know the full extent of this 'set' yet).
What we're discussing here is a principle that hasn't changed.
What I mean by outdated is that it has evolved to the point of exponentially diminishing risk. Unfortunately, that risk never reaches zero, so yes, the principles are still the same. At least they'll be the same until the next technological architecture level, and even that may or may not eliminate risk of some caching methods.
For SSDs, I envision a controller and memory (buffer) chip that can keep itself powered long enough to flush its own cache in the event of power loss.
*is a coffee addict*