Patrick @ STH on HDDs with low endurance - Impact on DSM settings?

Currently reading
Patrick @ STH on HDDs with low endurance - Impact on DSM settings?

716
388
NAS
RS1221+, RS819, RS217
Operating system
  1. macOS
Mobile operating system
  1. iOS
Patrick has an interesting video on HDD endurance, prompted by the relatively low endurance of the WD Red Pro drives:

watch

It is an interesting twist to look at the poor endurance of a spinner when compared to that of an SSD, especially with a preponderance of reads vs writes. Clearly he has a point and it is not the first time an issue has arisen with the rapid growth in HDD capacity revealing the underlying architecture limitations of the average SATA hard drive.

But the endurance rating limitation of HDDs being governed by the total of writes + reads is a serious issue (especially for the WD Pro and Plus) and he mentioned the impact of read-intensive background tasks such as ZFS scrubs, RAID amplification, management etc before we even get to the business of actually reading and writing data for client use.

Although not mentioned specifically, this looks equally applicable to DSM and BTRFS scrubs - reading all the data on a drive and comparing it with the metadata checksums. It is recommended to complete BTRFS scrubs every month and those read tasks will eat through the yearly endurance rating. As a simplistic example, BTRFS scrubs on a 90% full WD Plus and WD Pro in a single year:

14 TB WD Red Plus, endurance limit 'up to' 180 TB/year @ 90 % full
= 12.6 TB write + (12.6 TB read x 12 months)
= 163.8 TB
~ 91% of endurance used

20 TB WD Red Pro, endurance limit 'up to' 300 TB/year @ 90 % full
= 18 TB write + (18 TB read x 12 months)
= 234 TB
~ 78% of endurance used

As the above figures do not include any RAID, DSM or task overheads they are artificially low but it is clear to see that even a drive you write to once and do nothing more than data integrity checks will burn through the overwhelming majority of its 'up to' endurance in any given year. :eek:

In the video Patrick is his usual effervescent self but he does seem to have a very good point to make - it is remarkably easy to burn through the yearly endurance ratings. In the case of the Red Plus example above a drive filled just once does not have sufficient endurance remaining to do standard BTRFS scrubs, let alone all the other routine drive and data management tasks required of it. The Red Pro fairs little better as in reality as things like actually using the data plus more intensive RAID tasks (RAID expansion anyone?) will blow through the limit.

For those spinning WD Reds, should the recommended monthly BTRFS scrub be dispensed with? Is a scrub every 3 months enough to provide a meaningful balance of integrity and stay under the endurance limit? Is a 6-monthly scrub the maximum practical limit to preserve a drive for real-world use? Are drives manufactured with higher limits (eg 550 TB/year) also at risk of hitting their endurance limits?

I have always likened these massive SATA HDDs as a large house that you can only fill and empty via the letterbox; now it looks like the postman has serious limitations too.

☕
 
Endurance is specified as TBW terabytes written. Reading is not included, or am I missing a point?
Yes, you missed the point. :)

In this context (HDDs) it really is reads and writes. If you watch the video Patrick expands on this and makes the comparison with SSDs and their TBW spec.

[responding to this post had its own issues as my MBP keyboard locked-up the number 5 key so I had to hit the air compressor in a cold garage - reliability eh!]

👍
 
Bit rot and unrecoverable errors has only become relevant to me, as a small scale user, with the rise of seriously large and dense HDDs. My latest pair are 18 TB and at that size the chances of writing to them just once without an error becomes a risk in itself. Being stuck with the error correction of yesteryear with 512 byte emulation on a SATA drive does not help with the confidence level either.

Not that I even understand why SATA is so common on motherboards and NASes when SAS is so cheap and ubiquitous. It's like being stuck with an IDE drive.
 
Last edited:
WD does not mention endurance, but "workload rate", interestingly it is calculated based on the hours the drive is operational each year:

TB transferred x (8760 / recorded power-on hours)

So if the disk is only powered on 10% of the time: the 300TB is multiplied by 10 ---> 3000TB workload rate

Not sure what they intend to specify here.
It looks like they do not care only about the amount of data, but they care about the amount of data and the "power on" time of the RED pro disks.

Honestly I lost faith after the SMR issue anyway.
 
Not sure I am with you on the maths (but WD is not helping here). As I understand it, using 2 mythical drives:

Drive A - running 24hrs/365 days passes in 1 year a total of:
- 29 TB of writes + 270 TB reads = 299 x (8760/8760) = 299 TB workload = Ok as under 300 TB workload limit

Drive B - running 16 hrs a week passes in 1 year a total of:
- 2.9 TB of writes + 27 TB reads = 29.9 x (8760/832) = 314.8 TB workload = Bad as over 300 TB workload limit

Drive B is powered-up a lot less and only passes 29.9 TB of data in a year but when annualised using WD metrics you are through the workload limit (ie it is effectively 'worked harder' when in use).

All a bit weird and you are right, WD have already squandered a lot of good will.

I may be wrong in my interpretation of course.
 
Last edited:
I meant to say the same as you :) Changed the wording a bit. there is a strange thing if you only use the disk part time.

The Seagate Ironwolf range has the same 300 TB workload limit.

This exact topic was raised 6 years ago:
 
My oldest Seagate Constellation CS drives (8pcs) are spinning 6.7y and I have had them in operation for 7.5 years.
Zero relocated sectors for all of them still in perfect condition.

Follow vendor spec (Product manual):
Rated Workload: Average rate of <180TB/year

Few examples, from one of the 4 pools (this is about 1TiB capacity) in RAID1 from my Primary home NAS:
1647005170161.png

The read values are affected by:
- backup policy (backup NASes, C2)
- by BTRFS scrubbing (last 4y only before migration from Ext4)

As you can see the average Workload rate is over the defined by the vendor.

The Workload Rate for CMR drives has only an informative purpose, similar to AFR. Because it still matters a lot more how the user takes care of those drives/NAS/environment - if he doesn't overheat them, UPS matters, if the user does maintenance regularly (dust exists anywhere, even in a closed rack), ... and if the disk is under more useful monitoring than the DSM contains (HDSentinel in my case).
It will be diferent for HAMR/MAMR drives.

Another reason - I use data tiering:
- properly defined data to properly defined storage pool (I don't mix large video data with small documents). I have FolderSizes Storage management to find unused data (policy defined), duplicities, specific folder capacity, ...
- max. data capacity calculated for the pool almost 7.5y ago is still sufficient = I don't store any mess.
- I have an archive policy - primary NAS uses just data I need immediate. Archive/Backup NAS contains the rest of them.
Then I don't need to scrub more than is necessary for the specific disk drive.

Last: RAID1 anywhere, with a proper backup policy. Another impact to the scrubbing.
-------------------------------
How you can get LBA Read/Write values, when your HDD doesn't have such data stored in SMART starts:

for HDD LBA sectors written/read values you can use data from /proc/diskstats
Bash:
# Sectors Read

awk '/sd/ {print $3"\t"$6 * 524288}' /proc/diskstats
# where $3 is a device name

# where $6 is the sectors read value in 512kbytes (defined by drive's logical sector x1024)

# then you need convert the read value by 512x1024 =524288 to get sectors count value

# Sectors Write
awk '/sd/ {print $3"\t"$10 * 524288}' /proc/diskstats

# where $10 is the sectors write value in 512kbytes (defined by drive's logical sector x1024)

based on documentation:

The /proc/diskstats file displays the I/O statistics of block devices. Each line contains the following fields:

== ===================================
1 major number
2 minor mumber
3 device name
4 reads completed successfully
5 reads merged
6 sectors read
7 time spent reading (ms)
8 writes completed
9 writes merged
10 sectors written
11 time spent writing (ms)
12 I/Os currently in progress
13 time spent doing I/Os (ms)
14 weighted time spent doing I/Os (ms)
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

  • Solved
There is no such classification ... either drives are on the Compatibility List, or the Incompatible...
Replies
1
Views
2,085
  • Question
read reviews, make sure to purchase Enterprise/NAS rated boxed retail drives - not refurb or used if you...
Replies
3
Views
1,944
RAID and NAS migrations with live data are always risky business. Here's what I would do Go get an...
Replies
11
Views
2,107

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Trending threads

Back
Top