Take the 2-minute tour ×

We do software development (Visual C++) on Windows, and already had a few cases where developers using SSD disks with Windows XP had to replace their disks after a (one, 1) year of usage, because they were broken. (Timeframe 2010 - 2012)

Obviously, compiling a lot means a very high number of writes - Visual Studio Compiler likes to write a lot of temp files in addition to all the build artifacts created by a normal C++ project anyway.

Now, I know that the TRIM command is not supported on XP, but I always understood that to be a performance thing, not a longevity thing for the drives???

Also, given that some claim that a modern(ish) SSD drive should last 51 years with full write utilization, how can it be that a developer, even doing many compilations during an 8 hour working day, can trash his SSD -- and what has this to do with Windows XP (vs. Win 7)?

Note: This is a developer shop, so naturally everyone has his own clever explanation of this and that. But this is a developer shop, so the expertise of the people here lie with SW development, and not with HW reliability.

And given all the myths about SSD disks on the net, I really have a hard time finding reliable infos on why an SSD should fail earlier (or anyway) on Windows XP ....

DISCLAIMER: Note that I do not necessarily claim that these SSD disks really broke because they were used on Windows XP with a write heavy usage pattern. I'm asking whether there is any existing evidence (because my co-workers claimed so), that an SSD drive will fail earlier on XP than otherwise (because of missing TRIM or other reason) ...

Having followed a few links, I would like to especially highlight the most upvoted answer for the question SSD on Windows XP. (Note that this answer (from 2010) is a quote of the article -- from 2007 (!) -- it links to. The gist of the article/answer seem to be that SSD drives can go bust with lots of write operations and that, somehow(?), XP is worse in this regard. Looking at the 51-years-claim I linked to above, the statements in this answer don't make any sense to me.

Also, there's the MS article from 2009, where the only reference to TRIM and wear is:


But the same article states under Flash wears out:

At some point, a flash cell simply stops working (...) If frequently updated data (e.g., a file system log file) was always stored in the same cells, those cells would wear out more quickly (...) Wear leveling logic is employed by flash controller firmware to spread out writes (...) most devices will last years under normal desktop/laptop workloads.

So, while MS seemed it worthwhile to mention additional wear-time benefit under the TRIM command section, the also mentioned the drives firmware as the main factor to maintain the drive by spreading out writes.

Really, this leaves me quite confused !?! :-)

share|improve this question

closed as not constructive by techie007, EBGreen, random Mar 27 '12 at 2:44


Have you verified that the disks did break from wearing out the flash? How much data had been written to the disk? –  Oggy Mar 26 '12 at 13:22
The plural of anecdote is not data. –  EBGreen Mar 26 '12 at 13:28
@EBGreen - "The plural of anecdote is not data" - exactly :-) - That's why I'm asking here, whether there is any existing evidence or data on this topic, because quite frankly my google skills failed me on this one. (You find much more anecdotes than reliably looking data.) –  Martin Mar 26 '12 at 14:31
How this disks died? As the developer of some ssd life measurement tool, I can note that there is no difference between XP and 7, except noted by Shinrai. Win7 write a bit optimized data to page file and other system files, but there is no so huge difference. –  crea7or Mar 26 '12 at 15:05
@random - Was this an admin close? (Because only three votes?) How is this not constructive? I clearly state in the question that I'm not sure, and that "the net" is of no help! Btw.: The answers so far were really helpful, no "opinion, debate, arguments" in sight! –  Martin Mar 27 '12 at 11:41
show 6 more comments

3 Answers

One other big problem is partition alignment - Windows XP aligns to old disk style by default, but SSDs need 4KB alignment internally. Otherwise you're doubling the volume of writes because a lot of things will overlap internally. (I'm not really qualified to talk about this at extensive length, so maybe somebody can elaborate at this - it's not really my area of expertise.)

That said, I am still fairly surprised if your disks are failing this fast. SSDs can be pretty failure prone unless you're careful about what you buy - this wouldn't surprise me nearly as much from OCZ or Crucial SSDs as it would from Intel ones (which I can vouch for in dozens on XP machines with no problem).

My personal opinion? XP may not be helping, but it's probably mostly a red herring.

share|improve this answer
I've seen many OCZ and crucial SSDs fail quick, and have Intels still running strong, even in xp. Quality matters –  Canadian Luke Mar 26 '12 at 15:24
Windows 2003 lets you partition-align on format, so I expect XP would, too. Your explanation is good enough for this context. –  user3463 Mar 27 '12 at 8:03
@RandolphWest - XP absolutely does not support 4K alignment naturally, I'm afraid. I've always had to use a third party tool for it (although I think creating the partition with something other than the Windows installer, and then installing without formatting MIGHT work) –  Shinrai Mar 27 '12 at 14:10
@RandolphWest - You can't do anything natively in XP other than old style sector 63 alignment - you're stuck with 31.5KB. When I said '4K alignment' I meant 4KB sector sizes as opposed to 512 byte sector sizes, sorry for being unclear. It is in theory possible to do this by hand from within Diskpart but there's no way to do it from within the installer utility myself, is my point. (I believe Server 2003 is 4K-sector aware, so this is a difference, but don't hold me to that as I don't deal with Windows Server much) –  Shinrai Mar 28 '12 at 14:40
There is no way to do it from the installer itself, sure, but it IS possible to format the drive with correct partition alignment and then install onto it. I think we're agreeing here. –  user3463 Mar 28 '12 at 15:13
show 1 more comment

TRIM is also good for keeping the drive health up. The reason is simple: On writing a SSD swapps blocks very often for limiting the maximum count of write operations for each block.

On a SSD never trimmed the only available blocks for swapping are those from the reserved free space (blocks that are not directly accessible because the SSD has more flash memory available internally than it offers to the outside).

On a SSD well trimmed the pool of available blocks also contains those that are free on disk. Therefore the write operations can be spread among more blocks.

share|improve this answer
It's a myth. Windows does not save into pagefile very often. Mostly it's not a problem at all. Firefox, Chrome, Google Earth and even driver updates writes much, much more. –  crea7or Mar 26 '12 at 17:00
@crea7or - Robert didn't mention the pagefile at all in his answer ... ??? –  Martin Mar 27 '12 at 11:44
@Martin - yep, my false. "swapps" was interpreted as pagefile :) –  crea7or Mar 27 '12 at 11:50
add comment

I cannot visualize how different flavors of an OS can reduce the MTBF of an SSD! The whole idea of an SSD is to increase storage reliability, access times and life expectancy of the storage medium. How many SSD's has this happened to? Have you experimented with different SSD manufacturers?

share|improve this answer
"whole idea of an SSD is to increase storage reliability, (...)and life expectancy" - these two points are really quite new to me. I was under the impression that, especially with "first generation" SSD disks, life expectancy, due to the inherent limit of writes to a cell, was significantly worse than with traditional platter disks. –  Martin Mar 27 '12 at 11:38
in the sense of no moving parts vs. a spinning disc with moving heads.. as time moves forward, SSD's will get better, just like everything else which evolves! –  FrankComputerAtYmailDotCom Mar 27 '12 at 22:58
add comment
