Do not buy BX100 - buy a good SSD such as the Crucial MX200. The BX100 uses a totally different controller like Silicon Motion and is an unprotected SSD, the Crucial MX and M series are protected by power-safe capacitors and RAID5 bitcorrection.
We have talked about this before i think. Anandtech does not properly understand how power-loss protection works in my opinion. Not in the past and still you guys do not fully understand why power-loss protection is so crucial (pun intended) and Samsung can do without.The MX200 does not have full power-loss protection.
http://www.anandtech.com/show/8528/micron-m600-128gb-256gb-1tb-ssd-review-nda-placeholder
What does AHCI have to do with it?OP, RAID-0 will only improve performance of large transfer sizes and high queue depths because the drives are still bottlenecked by AHCI.
Do not buy BX100 - buy a good SSD such as the Crucial MX200. The BX100 uses a totally different controller like Silicon Motion and is an unprotected SSD, the Crucial MX and M series are protected by power-safe capacitors and RAID5 bitcorrection.
If you want to RAID0-them fine. It will roughly double your speeds of sequential I/O and random I/O (except blocking random reads) but even an SSD of double the speed will not translate into double the speed experience - your CPU will be a major bottleneck. So the actual speed increase is only modest. For loading games the additional speed would be on the threshold of being noticeable so it would have at least some benefit though.
But then go for the MX200 not the budget BX100 that is an SSD no one should buy.
The problem with unprotected SSDs like the BX100 is, that problems may occur without the consumer ever knowing about it. The SSD continues to function, but still there are strange errors of Windows, or a specific application or game, or boot problems, or hanging applications, or blue screens. All this while, the SSD may continue to function as if it were not to blame. But it is, because these problems can be the result of the SSD causing corruption. This can happen because these SSDs are unprotected and have neither RAID5 bitcorrection to protect against corrupted/unreadable NAND pages, or against corruption of the mapping tables (FTL) in case of unexpected power-loss. The latter happens far more than one might assume. Do not think: i have a power failure once a year so unexpected power-loss also means once a year. You can have zero power outages and still have hundreds of unexpected power-loss. Simply resetting your computer during the boot phase, a blue screen, or a loose power-cable can result in the SSD having unexpected power-loss. Even tidy shutdowns can cause this because various bugs can cause the power to be cut before the STANDBY IMMEDIATE command being processed by the SSD - which is the command to signal a tidy shutdown.
Do not buy BX100 - buy a good SSD such as the Crucial MX200. The BX100 uses a totally different controller like Silicon Motion and is an unprotected SSD, the Crucial MX and M series are protected by power-safe capacitors and RAID5 bitcorrection.
If you want to RAID0-them fine. It will roughly double your speeds of sequential I/O and random I/O (except blocking random reads) but even an SSD of double the speed will not translate into double the speed experience - your CPU will be a major bottleneck. So the actual speed increase is only modest. For loading games the additional speed would be on the threshold of being noticeable so it would have at least some benefit though.
But then go for the MX200 not the budget BX100 that is an SSD no one should buy.
I am not really sure what you mean with 'runt'. But the fact that your application says the download is complete, does not mean it has been flushed to disk. Data on the SSD or HDD is only safe as being permanently stored when the subsequent FLUSH CACHE command has been completed. This normally only occurs upon filesystem metadata writes. There can be quite some time between these flush-commands, depending on I/O traffic.Just because an SSD has power-protection capacitors, does NOT make it immune from glitches.
[..]
I've noticed occasional corruption. Specifically, I downloaded a file, my browser download history said the entire file was downloaded (and listed a size), but the file on-disk in the Windows 7 64-bit filesystem (native NTFS) was a "runt".
I think this is a wrong conclusion, but i respect your opinion.So, don't be afraid of getting a BX100, because the power-backup capacitors in the more expensive SSDs don't do all that much anyways for you.
I am not really sure what you mean with 'runt'. But the fact that your application says the download is complete, does not mean it has been flushed to disk. Data on the SSD or HDD is only safe as being permanently stored when the subsequent FLUSH CACHE command has been completed. This normally only occurs upon filesystem metadata writes. There can be quite some time between these flush-commands, depending on I/O traffic.
Normally flush commands are very sparse because of the performance impact these have. If all writes would be synchronous - meaning each write would be followed by a FLUSH command - then harddrives would write at about 1MB/s at the most or little over 50K/s for random writes.
I think this is a wrong conclusion, but i respect your opinion.
It still results in data corruption, so, I beg to differ, it still is a problem.But you are correct in the sense that Crucial has only partial power-loss protection. It will still lose the contents of the DRAM buffercache. But that is not any problem
Thing is, this is a corner case, and while I do agree that SSDs should have power-loss protection, and it should be pointed out in reviews, but, realistically, power-loss isn't the #1 factor for most people.;this is also the case for all harddrives used in the last 20 years. Filesystems of the first generation (FAT16/FAT32, Ext2, UFS) are vulnerable to the loss of the DRAM contents when write buffering is enabled. Without write buffering, harddrives can only write at 1MB/s. Starting from the 2nd generation of filesystems (NTFS, Ext3/Ext4, UFS2+SU) the loss of the DRAM contents is not a problem as long as FLUSH commands are adhered to. The latter is where all the fuss is about. SSDs can corrupt recent writes even across flush commands. So the write has been acknowledged by the SSD, but will still be lost some cases of unexpected power-loss.
It is only a problem for first generation filesystems, which nobody uses these days. All 2nd generation filesystems can cope with lost recent writes up to the last FLUSH CACHE command. If it loses writes beyond this boundary, then the filesystem is in trouble - especially with reordered writes. That is why you need BBU or Battery Backup Units for unsafe write-back buffercache as used on Hardware RAID adapters like Areca. You do not need BBU for a normal harddrive.It still results in data corruption, so, I beg to differ, it still is a problem.
No they don't. Less than 0,1% of consumers have a UPS. Even with a UPS, that does not mean you will not have unexpected power-loss. Look in the SMART data for 'Unexpected Power-Loss Count' and explain to me if you had as many power failures as the number there suggests. Then, how do you explain the high number?Lots of people have UPS systems these days
You are assuming one write transaction is sufficient when you have a power loss event.It is only a problem for first generation filesystems, which nobody uses these days. All 2nd generation filesystems can cope with lost recent writes up to the last FLUSH CACHE command. If it loses writes beyond this boundary, then the filesystem is in trouble - especially with reordered writes. That is why you need BBU or Battery Backup Units for unsafe write-back buffercache as used on Hardware RAID adapters like Areca. You do not need BBU for a normal harddrive.
So what you say is incorrect to my knowledge.
Either having a UPS or laptop (which have batteries) is far over your .1%, I am thinking over 60% if not more.No they don't. Less than 0,1% of consumers have a UPS. Even with a UPS, that does not mean you will not have unexpected power-loss. Look in the SMART data for 'Unexpected Power-Loss Count' and explain to me if you had as many power failures as the number there suggests. Then, how do you explain the high number?
Hmm?Right... power outages have nothing to do with unexpected power-loss. The former is about loss of AC power, the second is about unsafe shutdowns without informing the SSD that a power loss is about to occur. Using the reset button at BIOS phase is enough to trigger this.
Crucial has decent hardware power-safe capacitors and thus its protection is much better than Samsung. It allows their SSDs to be used for more than casual storage, since Samsung SSDs theoretically can have problems when used in a RAID array -- just imagine what would happen if you have a RAID0 array and one or more SSDs revert to an earlier state, but the other SSDs in the RAID0 array do not, or revert to a different state. Then you still have filesystem corruption even though the SSD itself is in a consistent state.
NVMe just decreases the latency, which is very useful, but does not change any of the above as far as i know.
Sounds interesting. Where can I read about that? ThanksI would opt 4x Crucial MX200 using only half of storage so you can utilise them as SLC SSDs instead of MLC. That would give you the best of all latency, even better than the latency of MLC SSDs like the Samsung 950 Pro (which uses MLC instead of TLC like the 840 (EVO) and 850 (EVO) do).
Alright, but this is application-level corruption/inconsistency, not filesystem or storage device (LBA) level inconsistency. The application is responsible for its own stuff. The filesystem only guarantees that application writes that are synchronous to be completed before the I/O request is finished. Asynchronous writes by the application will be finished immediately if the buffer allows, but unlike sync writes the async writes have no such guarantee.You are assuming one write transaction is sufficient when you have a power loss event.
I am talking about if you have lots of data (say an archive), and if you are not on battery, then the last write transaction before the power loss event will still result in the archive being corrupted if it didn't finish writing all of it.
You cannot be serious about that? We are talking about ordinary consumers? You are saying 60% of consumers have a UPS? Seriously? Well if you count the laptop battery as UPS that would indeed increase the number significantly, from 0,001% to 20% maybe. But still, that is far below the number you suggest.Either having a UPS or laptop (which have batteries) is far over your .1%, I am thinking over 60% if not more.
Not really, as far as i know the STANDBY IMMEDIATE command is responsible for that. If you have more information i'm all ears.All my SSDs show 0 for that stat. As to what triggers an "unexpected power-loss"event, it can vary from each SSD maker.
Which is not what i disputed, is it?If you read the article I linked, you would know that the capacitors in all Crucial/Micron client drives only protect lower pages from corruption.
Also not what i disputed.The capacitors provide absolutely zero protection for any data in the DRAM
Now this is some good point you make. And a very crucial one. Because even if it is true what i asserted, that Crucials capacitors allow for the pending write to succeed not to cause corruption to the MLC 'lower pages' as you describe, the FTL/mapping tables that are cached in DRAM might still be newer than what is written to NAND. And as such, the loss of the DRAM contents does not only lose recent async writes (buffered writes) but also causes the loss of the newer FTL version. And as you say, the only valid defence against such an occurrence would be to provide journalling of the mapping tables. If this is true, then the protection is not what i anticipated and asserted. And you would be very right to set this straight. So i guess i owe you an apology - it seems i did not fully understand the situation properly.including the FTL, meaning that Crucial is also resorting to journaling to recover the FTL in case of a sudden power loss.
Well, aren't there quite a bit of stories about strange things happening with SSDs? We all know the stories about FTL corruption where you need to provide power to the SSD for half an hour or so, to allow it to make its FTL consistent with the data again. I think we can all understand that this is due to an FTL inconsistency - where the FTL does not match the data stored on NAND, very likely due to unexpected power-loss.I think you are exaggerating the need for full power loss protection in client usage. If data corruption was a significant issue, then we would have people telling their stories and complaining about it in this very forum.
Journalling or full power-loss protection, i do not know any other ways to protect this risk? Do you?It is true that client SSDs are vulnerable to power losses to some extent, but there are proper mechanisms in place to protect the FTL and data-at-rest.
Alright now i understand what you mean. But AHCI does not have any direct link with RAID0. You only meant to say that while RAID0 increases all performance specs, it cannot increase blocking random reads (commonly known as 4K QD=1) - fair enough!![]()
Throughput and IOPS are inverses of latency, so any decrease in latency will result in higher performance. That's why NVMe is more than just a marketing gimmick because it actually improves 4KB QD1 random performance substantially [..] RAID-0 doesn't help with that because it only increases parallelism - it doesn't improve the minimum latency at all.
RAID0 doubles Random IOps just as it doubled sequential I/O. But, there is one exception. It will not increase blocking random reads, commonly referred to as 4K QD=1 or simply '4K'. This is only true for reads though - writes even with qd=1 can be improved with RAID0 thanks to write buffering. But with reads this is not possible.Does Raid 0 have any affect on 4k read and writes?
NVMe does increase the most important performance spec; 4K blocking reads. This is the most important performance spec for consumers and one that RAID0 (both internal & external) cannot accelerate. So NVMe for consumers is very useful. Though still, a faster SSD does not translate into vastly improved speed experience. A single SATA/600 SSD with AHCI-interface is already very fast to let the CPU be the bottleneck most of the time.Last I checked it didn't improve them at all which is where the NVMe interface will shine.
Not sure where you can. But using the MX200 250GB as SLC SSD is simple: simply do not write more than half the LBA/storage capacity. You can force this by using partitions and not partition more than 50%. You might want to partition 45% to provide some overprovisioning as well. So 110GB partition would be good. Then you have a very cheap killer-SSD that operates as SLC SSD at very marginal consumer-grade cost. I like it! :awe:Sounds interesting. Where can I read about that? Thanks
Is SLC enough to give it 300,000 iops?