{"id":414,"date":"2023-12-19T10:07:10","date_gmt":"2023-12-19T10:07:10","guid":{"rendered":"http:\/\/192.168.8.136\/wordpress\/?p=414"},"modified":"2024-01-25T14:23:20","modified_gmt":"2024-01-25T13:23:20","slug":"rpi-nas-extras-hdd-s-m-a-r-t","status":"publish","type":"post","link":"https:\/\/mpr-projects.com\/index.php\/2023\/12\/19\/rpi-nas-extras-hdd-s-m-a-r-t\/","title":{"rendered":"RPi NAS: Extras – HDD S.M.A.R.T."},"content":{"rendered":"\n

S.M.A.R.T. stands for Self-Monitoring, Analysis, and Reporting Technology. Practically that means that HDDs that support SMART can run self-tests to diagnose problems and report them to us. Although Greyhole can provide our NAS with redundancy, i.e. no data is lost if an HDD fails, it’s still good to know how healthy our HDDs are before we decide to use them and once they’re in operation. So in this post we’ll have a little look at how we can use SMART.<\/p>\n\n\n

This post is part of a series about building a Network-Attached Storage (NAS) with redundancy using a Raspberry Pi (RPi). See here<\/a> for a list of all posts in this series.<\/p>\n\n\n\n

\n\n\n\n

Basics<\/h2>\n\n\n\n

We’re going to use smartmontools<\/a>1<\/a><\/sup> to access the SMART features of our HDDs. Let’s plug in a HDD and have a look what information we can get. Note, there’s no need to mount the drive once it’s connected to the computer (although it won’t hurt if you do). The drive I’ve just connected, which I salvaged from an old Laptop, has path \/dev\/sdb<\/em>. We can get some basic information about it with<\/p>\n\n\n\n

sudo smartctl -i \/dev\/sdb<\/code><\/pre>\n\n\n\n
which should return an output as shown below:<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
We’re mainly looking at the last two lines, which tell us that SMART is available and enabled. If it’s available but not enabled then you can enable it with<\/p>\n\n\n\n
sudo smartctl --smart=on \/dev\/sdb<\/code><\/pre>\n\n\n\n
Let’s now check if a selftest has been run before. We can use the command below to list selftests.<\/p>\n\n\n\n
sudo smartctl -l selftest \/dev\/sdb<\/code><\/pre>\n\n\n\n
I have never run a selftest on this drive so the output is<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
So let’s run a test to see how the drive is doing. There are a few options available. Let’s start with a short test. According to the man pages the short test “check[s] the electrical and mechanical performance as well as the read performance of the disk”.<\/p>\n\n\n\n
sudo smartctl -t short \/dev\/sdb<\/code><\/pre>\n\n\n\n
This command starts the test and tells us to come back later (see the image below). The short selftest is fast (2 minutes for this drive) and it runs in the background. If you’ve mounted the drive then you can still use it during the self-test, although it may be slower than without the selftest. You can also run the selftest in the foreground with command sudo smartctl -t short -C \/dev\/sdb<\/code>. In that case no partitions of the drive should be mounted.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
After about two minutes we can list the selftests again.<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
According to the last line the test was completed without an error. That’s great! Let’s try to get a bit more information by running<\/p>\n\n\n\n
sudo smartctl -x \/dev\/sdb<\/code><\/pre>\n\n\n\n
The output of that command can be quite long. I’m going to focus on what I think is most important for us.<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
This is a table that describes certain attributes of the drive. The first point to note is that these attributes are not standardized. So there is no document that describes exactly what the attributes mean. Their exact meaning is set by each manufacturer and that information is typically not published. So the table is not as useful as it could be but there’s still quite some information it it.<\/p>\n\n\n\n
The second column contains the name of the attribute. The last column its RAW_VALUE<\/em>. That value typically has some physical meaning. For example, RAW_VALUE<\/em> in the row with id 194 shows a value of 30, which means that the temperature of the drive was 30 degrees Celsius.<\/p>\n\n\n\n
The raw values then get converted to some encoded value VALUE<\/em>. That conversion takes place inside the drive so how exactly that happens is up to the manufacturer. The values can be in the range 1 to 253. A higher value is usually better. Some manufacturers don’t use 253 as the highest value for all attributes but some other value, for example 100. WORST<\/em> refers to the worst value that was recorded for an attribute2<\/a><\/sup>. Finally, THRESH<\/em> contains a threshold value which is set by the manufacturer. If VALUE<\/em> falls below this threshold then there is an increased risk of drive failure.<\/p>\n\n\n\n
Look h<\/a>e<\/a>re<\/a> for a general description of these attributes (remember, their exact meaning varies by manufacturer). A few of them, like Read Error Rate<\/em>, are quite important because they can indicate imminent disk failures.<\/p>\n\n\n\n
I’ve also run the commands above with another old HDD and I got the following result. You can see in the row with id 1 that the drive has failed.<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
About Load Cycle Count<\/h3>\n\n\n\n
I’ve seen a few discussion in online forums about load cycle count<\/em>. Remember that HDDs have a head<\/em> which moves around to read and write data. When a disk is not used then the head can be moved into a parking position<\/em> where it’s not directly above the disk. This is done to protect the disk from damage3<\/a><\/sup>. Load cycle count<\/em> counts how often the head has been parked. Repeatedly parking the head (many thousands of times) can cause some wear and tear. Disks are typically rated for a certain number of load cycles. For example, depending on the model, WD HDDs are typically rated for 350,000 to 600,000 cycles. That’s quite a large number.<\/p>\n\n\n\n
In the main part of this series I assumed that we access our NAS three times a day (which is roughly my access pattern). If the head gets parked after each access then we have three load cycles per day. That’s 1095 per year, so we’ll only reach 350k cycles after 319 years. If we access the disk once every 10 minutes then we still have more than 6.5 years before we reach 350k load cycles. So under normal circumstances we shouldn’t have to worry about the load cycle count in our NAS.<\/p>\n\n\n\n
Long Selftest<\/h2>\n\n\n\n
In the first section we ran a short selftest. Now let’s run a more extensive test. This test is similar to the short test but it goes over the drive a lot more thoroughly.<\/p>\n\n\n\n
sudo smartctl -t long \/dev\/sdb<\/code><\/pre>\n\n\n\n
It can take many hours for this test to finish. So it may be a good idea to run it overnight. Note, depending on your setup, the test may get interrupted and sudo smartctl -l selftest \/dev\/sdb<\/code> may report an error Interrupted (host reset)<\/em>. In my case it worked fine on the Raspberry Pi but not on my main computer. We can prevent this error by running<\/p>\n\n\n\n
sudo watch -d--cumulative -n 15 smartctl -a \/dev\/sdb<\/code><\/pre>\n\n\n\n
right after we start the extended test. This command will run sudo smartctl -a \/dev\/sdb<\/code> every 15 seconds and it will highlight any changes in the output (so we can see the progress of the test). We don’t have to use option smartctl<\/em> with option -a<\/em>, we could use any command that queries some information from the drive. The important point is that we regularly query the drive so that it’s kept awake.<\/p>\n\n\n\n
Note, the command doesn’t stop when the selftest has finished. You’ll have to do that manually with Ctrl-c.<\/p>\n\n\n\n
Scheduling Regular Checks<\/h2>\n\n\n\n
We probably don’t want to run the selfcheck manually for every drive in our NAS. So let’s automate those checks. I’m going to run a long self test once a month. We could use the systemd service called smartd<\/em> that’s included in smartmontools<\/em>. However, I don’t think it’s appropriate for our NAS so we’ll first go over using cron<\/em> for scheduling checks and then briefly discuss why we’re not using smartd<\/em>.<\/p>\n\n\n\n
Cron<\/h3>\n\n\n\n
Cron is a utility that allows us to schedule when certain programs should run. We’ll use it to periodically (monthly) run a script that<\/p>\n\n\n\n