NAS Speed SSD -v- Spinners

Hard drives take longer to come out of sleep.

Hard drives have uncorrelated failures. This means building a RAID array with them, without thinking about details, is the correct thing to do. when one drive fails, you'll go to Degrade state and deal with it. It could be many days before a second drive would fail. The second drive does not "sense" that the first drive failed. One drive could fail at 5000 hours, the second drive at 55000 hours. These are uncorrelated.

SSDs on the other hand, have correlated failures. A worst case would have been, if you selected four Intel 2TB drives. Intel brick both reads and writes at end of life (at 1200 TBW). The array can go through both Degrade and Fail status the same day, because all four of the Intel drives could receive the same number of writes, and their "computed service life behavior" on all four units will be the same. Their failures will cluster at end of life.

If you use four identical SSDs from a product line that does not brick reads or writes at end of life, that is better. They will blow errors. They will corrupt data. But they will not go through Degrade and Fail on the same day while you're away on a jolly.

You can mix SSDs together. Install an Intel 2TB, a Kingston 2TB, a Samsung 2TB, a TeamGroup 2TB and those will fail differently.

If a NAS is actually designed for SSD usage, it will be reading the SMART table from each drive, once a day, and using the computed end of life to give warnings to the user ("drive 4 has

23 days remaining"). Maybe if 5% of device life is present, it will be giving alerts to make frequent backups, and/or change out unit, before the array goes down the toilet.

Summary: For SSDs, either the user provides the service intelligence, or the NAS does. For HDD, the normal assumptions of uncorrelated failure are met, and maintenance states are normal and expected degrades, with sufficient time to go from degrade back to normal.

HDD are a little slower at returning to service after a nap. They can use more power. SSDs can be slower to come out of sleep than you might think, but the HDD is a lot slower by comparison.

Paul

There is another approach. Use spinning discs if you can't afford to use SSDs. Helium filled spinning discs are getting affordable, but a similar capacity of SSDs might not be for most people.

If using SSDs buy them second hand from different sellers. That will give a random distribution of usages. They will already be burned in so you will avoid infant mortality. Most of the SSDs I have bought on eBay have had very low usage. Good quality drives such as Samsung

850 or 860 Pro have much greater write endurance than they are rated for. A colleague tried to test an 850 PRO to destruction by continuously writing random data to it and reading it back. Many months later he gave up having had no errors and having written several times the rated endurance.

John

If you're concerned with speed, then RAID6 seems an odd choice, it gives the same usable capacity as RAID10, it's slower at reading and slower at writing, it will burn up your SSD write endurance sooner ...

Yes RAID6 can survive *any* two SSDs failing, where RAID10 can survive any one SSD failing or *some* combinations of two SSDs failing, but as we all know, RAID is not a ...

Many thanks for all the replies, much appreciated :-)

It seems that I am more likely to get a catastrophic failure if I use the same make/model of SSDs whereas using spinning drives I am more likely to get warning between failure of individual drives. I accept there are no absolutes, just likelihoods.

For my NAS I am more concerned with reliability and a higher likelihood of recovering from a disk failure than speed and now I have re-vamped my setup it will be the last link in a chain of backups i.e. backup of last resort. I appreciate RAID is not a substitute for a backup but in this case the NAS itself will be one of several local backups.

Still nothing off site, bit wary of the cloud since my password spreadsheet was hacked from DropBox.

Thanks again.

Much depends on your application. For things like streaming video content, you are not going to see any practical difference - fast enough is good enough. If you are running other servers on the NAS that can benefit from very fast random access times (DB server, or VM virtual drive hosting) then you should see and improvement with SSD even if the network bandwidth limits the ultimate max throughput.

Does your QNAP have multiple ethernet ports? If so it likely supports link aggregation when connected to a switch capable of doing that. That can remove some of the network bandwidth limit in the sense that any single gigabit connected device will still max out at ~100MBs, but it can cope with multiple clients in parallel at an aggregate total throughput exceeding any one gig ethernet link.

(I run a mixture of IronWolf and IronWolf pro drives in mine after having the original batch of WD "Red" drives fail at various points. I have never really found performance a problem - but I don't thrash it that hard. I do use link aggregation with its 4 gig ethernet ports though).

Yes. But it does depend on network speed.

If you have a 1Gb/s transfer rate, that is a bit less than e.g, a SATA spinning rust drive BUT....

...NOT if you are looking at random seeks.

The SSD scores because the seek time is essentially irrelevantly low.

And people are now looking at faster Ethernet. 10Gb/s is not unheard of and higher exists

And that really would benefit from modern SSDs that don't use SATA

Now I do not expect speed from my NAS. Its there to store data, not load programs from. As long is it can support video streaming I'm ok with that

Your mileage may vary.

Its all bollocks anyway because SSDs fail when cells die, not at some arbitrary number of writes. Cells do not instantly die at an arbitrary point, they degrade over time and eventually reach a threshold where the error correction can no longer cope

And if you cared enough you would monitor the SSD using SMART and replace your drives the moment one of them started dumping blocks as unusable

e.g.,,,

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x0032 100 100 050 Old_age Always - 0 5 Reallocated_Sector_Ct 0x0032 100 100 050 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 050 Old_age Always - 27441 12 Power_Cycle_Count 0x0032 100 100 050 Old_age Always - 118

160 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 0 161 Unknown_Attribute 0x0033 100 100 050 Pre-fail Always - 100 163 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 8 164 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 85154 165 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 326 166 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 150 167 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 172 168 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 7000 169 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 98 175 Program_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0 176 Erase_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0 177 Wear_Leveling_Count 0x0032 100 100 050 Old_age Always - 0 178 Used_Rsvd_Blk_Cnt_Chip 0x0032 100 100 050 Old_age Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 050 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 050 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 050 Old_age Always - 56 194 Temperature_Celsius 0x0022 100 100 050 Old_age Always - 40 195 Hardware_ECC_Recovered 0x0032 100 100 050 Old_age Always - 1406121 196 Reallocated_Event_Count 0x0032 100 100 050 Old_age Always - 0 197 Current_Pending_Sector 0x0032 100 100 050 Old_age Always - 0 198 Offline_Uncorrectable 0x0032 100 100 050 Old_age Always - 0 199 UDMA_CRC_Error_Count 0x0032 100 100 050 Old_age Always - 0 232 Available_Reservd_Space 0x0032 100 100 050 Old_age Always - 100 241 Total_LBAs_Written 0x0030 100 100 050 Old_age Offline - 290950 242 Total_LBAs_Read 0x0030 100 100 050 Old_age Offline - 58331 245 Unknown_Attribute 0x0032 100 100 050 Old_age Always - 426654

You can monitors things like Raw_Read_Error_Rate and Reallocated_Sector_Ct and if they start to show any activity at all, replace the drive, Or wait till they get sufficiently high that you get worried.

There is more in there too - UDMA_CRC_Error_Count means a data sector needed the CR to correct the data, and Available_Reservd_Space is spare memeory to use to replace bad blocks

It not simple 'times up. i'm dead'

I look at my drives every so often to see what's what. SSDS I now have have been replaced not because they went bad but becuse the motherboards in the machines they were in died, a far more serious problem that an uncorrectable block error in an SSD.

You have been misinformed. Research the topic online if you dont believe me.

SSD failures are down to gradual doping migrations that affect the ability of the cells to retain data, This is a function of the actual silicon quality the temperature and how often they have been used.

And in a twin disk setup unless you are using pure mirroring that will not be the same for either disk

Essentially given you get past the 'manufacturing fault' early stage, SSDs show the normal gradually rising error rates with age and use and temnperature that any electronics does, and they are built to deal with that by error correction and moving bad blocks out of the way and using new ones

It is all recorded on the drive and is all accessible bia SMART

Simply back one disk up to the other every night. RAIDS is pointless. RAIDS is about speed and accessibility - not backup

If the backup dies, simply put in a new one If the primary dies, put in a new one and restiore from the second. You lose (up to) 24 hours of data but that us better than losing all of it

Build yourself a fireproof box and pout it in there.,

Frankly, if my house catches fire, my personal data is not the first of my concerns. Although I probably would grab the server and race outside with it

This is (unfortunately) not true.

The bricking policy is unrelated to SMART, in the sense that Intel devices do not brick because the device state is "poor".

They brick when exactly 600TBW has expired. No more or no less. Once the average location receives 600 writes (or whatever the technology indicates is the number of writes), the drive just bricks. It does not even go read-only. It just... stops working.

This is why, as a consumer, you have to study which companies have which policy.

Intel Device totally stops responding, after each cell written 600 times.

xxxxx Some companies, their drive goes read-only after 600 writes per cell. This allows a final backup to be made, before retiring the device.

yyyyy And a few SSDs have no policy at all. You can use them until the critical data corrupts (loss of map), or, there is some calamity related to spared out blocks.

Some of these policies were tested a long time ago, in a test series that bashed some drives continuously. And one of the drives (one without an end of life policy), it lasted about twice as long as predicted, and it corrupted while in service.

If a NAS is not prepared to monitor the hardware properly, then the user had better be aware of this sort of issue, and check the SMART values once in a great while. Move a drive over to another machine, a machine that won't "hurt" the drive, and check out the SSD portion of the statistics.

for desktop users, you can get the manufacturer "TookKit" and install that, and it reads the SMART once a day, records the Total LBA Written value. It works out the delta, and from that, computes how many more years the drive will last, at that rate of consumption. That's an example of a derived statistic you can get, without becoming a SMART table expert. Not all the ToolKits are worth installing, but a few of them are good.

Paul

The deal is, once you start doing stuff like this, your name is ruined forever.

The only way you can redeem yourself, is to carefully document for each model, what your policy is on end-of-life.

Every time I read these threads the story changes. There are also customer queries on the Intel forum you can read, if you are bored and there are no stamps to collect.

Paul

No any ones I have heard of

I do not believe anyone has that policy today, and 600 writes is impossibly small

E.g. Kingston quote lifetime not in writes, but in hours with an MTBF which simply does not suggest an exact cut off....

"Nevertheless: The flash cells, which electronically store data onto an SSD device, have a clearly defined life span, in contrast to traditional magnetic storage devices. After a limited number of write-erase cycles, this becomes critical, since the flash memory of an SSD ages with every write process. Manufacturers usually state 1,000 to 100,000 write-and-erase operations.

The considerable range in the lifetime of an SSD is related to different storage technologies:

- Single-level cell SSDs (SLC) have a particularly long life, although they can only store 1 bit per memory cell. They can withstand up to 100,000 write cycles per cell and are particularly fast, durable, and fail-safe.

- Multi-level cell SSDs (MLC) have a higher storage density and can store 2 bits per flash cell. They are more cost-effective than the SLC type but can only tolerate up to 10,000 write cycles per cell.

- Triple-level cell SSDs (TLC) can hold 3 information bits per memory cell. However, at the same time, life expectancy can drop to 3,000 memory cycles per cell.

- Quad-level cell SSDs (QLC) accommodate 4 information bits per cell. Reduced costs, more storage capacity, and higher storage density are also associated with a shorter service life with this type of device. Manufacturers usually only guarantee 1,000 write or erase cycles per cell.

Although the range in SSD life spans is considerable, all SSD types have a sufficiently high life expectancy with moderate use (with some limitations, including for QLC SSDs)."

So no absolute sudden bricking, just data degradation, followed by remapping of 'bad blocks' and finally drive failure.

And if you don't get greedy on storage space, up to 100,000 write operations. Or more.

IBM may have had some policy once, but it is in no way representative of drives on sale today.

If the drive is big and the data write rate slow, as is typical in a domestic NAS, the things should do 10+ years.

Which is better than most hard drives.

I have a friend who used to burn those out in under a year. 24x7 massive data files being written and read. Doing some kind of numerical analysis

Yes, yours is

Oh dear, a thread relating to an IBM drive 8 years ago?

And you are still touting this as 'expert knowledge'

I don't give a s*it what is on Intel forums 8 years ago I care what is common knowledge on drives available today. As produced by manufacturers.

I've shown you evidence that what you say is bollocks,. Apologize, and move on

As SSDs have moved from SLC to MLC to TLC the number of write cycles has dropped and dropped, by an order of magnitude per generation, now we're at QLC some only have an endurance of 100 writes per cell ... the only thing that stops them dying as soon as you look at them is the increased capacity of the device.

No they haven't dropped that far. Even for QLC

And if you are buying QLC for a NAS you need your head examining anyway.

I have an Intel SSD with writes greater than 600 times capacity. It works fine. It is quite old as SSDs go. Actually it is just plain old as anything PC goes, but it still works fine.

There is not. Network speed is the limiting factor.

My NAS has 10gigE and can fill 900meg/second from four spinning HDDs.

Cheers - Jaimie

RAID gives you continuity, you can carry on using the NAS while sourcing+installing a replacement drive.

Only backup gives you a backup.

If you have 4x4Tb in a raid5ish config, then I'd suggest getting a 12tb USB drive to backup to. raid6? Get an 8tb.

Cheers - Jaimie