7

I'm about to get a couple brand new HGST DeskStar 4TB 3.5" SATA hard drives. Are there any recommended practices these days I should perform before I start using them and entrusting my data to them, especially since they're still in the initial warranty period?

Typically, I just stick new drives in, fdisk them, encrypt if I need it, format with ext4, and go, though this time it'll be ZFS (via ZoL). When I get the time, I hook them into smartmontools so smartd can keep an eye on them, but that's about it.

Should I look at any particular SMART values at the beginning? Should I write ones, zeroes, or random data across the full length of the disk and, if so, read it all back? Should I leave it powered on for a full 30 days and keep an eye on anything? Should I verify APM settings are turned off for the drive so there is no premature wear from frequent spin-downs?

Update 7 Oct 2017: I followed the suggestions in @Xen2050's answer and @sawdust's comment.

I got the drives and I'm ready to begin testing them out. I created a script capturing Xen2050's recommendations.

#!/bin/sh

AWK=/usr/bin/awk
CLEAR=/usr/bin/clear
GREP=/bin/grep
SLEEP=/bin/sleep
SMARTCTL=/usr/sbin/smartctl

EXIT_SUCCESS=0
EXIT_INSUFFICIENT_ARGS=1

usage() {
   cat << END_OF_FILE
USAGE

   ${0} interval device

EXAMPLES

   ${0} /dev/sda

END_OF_FILE
}

runIteration() {
   runIteration_device=${1}

   #${HDPARM} -B ${runIteration_device} | ${GREP} 'APM_level'
   #${HDDTEMP} ${runIteration_device}
   #${SMARTCTL} --attributes ${runIteration_device}
   ${SMARTCTL} --attributes ${runIteration_device} | ${GREP} -E '(ATTRIBUTE_NAME|Temperature_Celsius|Current_Pending_Sector|Pre\-fail|Power_On_Hours|Power_Cycle_Count|Load_Cycle_Count)' | ${AWK} '
   {
      for (i = 1; i <= NF; ++i) {
         len=20;
         if ((i != 3) && (i != 7) && (i != 8)) {
            s = substr($i, 0, len-1);
            printf("%-4s", s);
         }

         if (i == 2) {
            printf(sprintf("%s%0" (len-length(s)) "s", "", ""));
         }

         printf(" ");
      }

      print "";
   }'

   ${SMARTCTL} --get=apm ${runIteration_device} | ${GREP} '^APM'
}

exitCode=${EXIT_SUCCESS}

if [ ${#} -eq 2 ]; then

   interval=${1}
   device=${2}

   while [ 1 ]; do
      ${CLEAR}
      runIteration ${device}
      ${SLEEP} ${interval}
   done

else

   exitCode=${EXIT_INSUFFICIENT_ARGS}
   echo ${0}: Insufficient arguments 1>&2
   usage 1>&2

fi

exit ${exitCode}

Test Setup

I have two of my four new drives plugged into two USB docks at a time that are sitting on a desk simply because this computer has no SATA ports available. I'm not sure whether I should expect the temperature to be higher or lower than inside an enclosed chassis with power supply fan running.

Because these are USB docks, I ran into some trouble I hadn't seen before. Although I could see the devices as /dev/sda and /dev/sdb, any smartctl commands resulted in an error last night. lsusb reported the docks are JMicron Technology, and a quick Google search indicated I needed to specify the --device option. After trying a few things out, I gave up on it as it didn't seem to work.

Tonight, I tried again without --device and it's working better for no apparent reason.

Also please keep in mind that I'm running this on a computer that is disconnected from the network (purely because I have no place to plug in an Ethernet cable). As a result, I'm trying to capture my notes here by running the corresponding smartctl commands on this laptop, pasting the output, and massaging values to match what I see on-screen of the test PC. I mention this because I caught myself missing the update of one value after pasting, so I want to apologize in advance in case anyone gets confused reading output below that does not make perfect sense because values look wrong. (FYI the value I missed was a VALUE/WORST for a Temperature_Celsius when I updated a RAW_VALUE.)

This also means I had to hand-type the script above onto the test PC. I believe I typed everything correctly, but there's always a chance I missed a comma or semicolon somewhere.

I performed the steps in the following sections twice--once with the first two drives, then again after powering everything off, replacing the drives with the remaining two, and then powering everything back up. I have annotated any differences from the second run where applicable.

OK. Now onto the fun part...

I booted up the PC with a live CD of System Rescue CD version 5.0.3. After I was at a prompt, I monitored the log:

# tail -F /var/log/messages

I powered on each of the USB docks and watched the messages come up for /dev/sda and /dev/sdb.

Run SMART Attributes Monitoring Script

To run the script, I typed:

# ~/scripts/hdd_init_checks.sh 60 /dev/sdX

for each disk (sda and sdb).

I'm not aware if polling too frequently wears anything out on the drive, but I figured once per minute should be enough for the duration of this.

The initial parameters were identical for the two drives:

ID#  ATTRIBUTE_NAME        VALUE WORST THRESH   WHEN_FAILED RAW_VALUE 
1    Raw_Read_Error_Rate   100  100  016    -
2    Throughput_Performa   100  100  054    -
3    Spin_Up_Time          100  100  024    -
5    Reallocated_Sector_   100  100  005    -
7    Seek_Error_Rate       100  100  067    -
8    Seek_Time_Performan   100  100  020    -
9    Power_On_Hours        100  100  000    -
10   Spin_Retry_Count      100  100  060    -
12   Power_Cycle_Count     100  100  000    -
193  Load_Cycle_Count      100  100  000    -
194  Temperature_Celsius   250  250  000    -    24   (Min/Max
197  Current_Pending_Sec   100  100  000    -
APM level is:     Disabled

Run SMART Tests

I started running the SMART tests; however, smartctl --capabilities reported neither of these supported the conveyance self-test. Oh well.

# smartctl --capabilities /dev/sdX
...
                                    Self-test supported.
                                    No Conveyance Self-test supported.
...
Short self-test routine 
recommended polling time:    (   2) minutes.
Extended self-test routine
recommended polling time:    ( 571) minutes.

Run Immediate Offline Test

I began with the immediate offline test for each of sda and sdb, but first I checked smartctl --capabilities /dev/sdX for each drive:

Offline data collection status:  (0x80) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Enabled.
...
Total time to complete Offline 
data collection:            (  113) seconds.

Then, I began the immediate offline test:

# smartctl --test=offline /dev/sdX

Testing has begun.
Please wait 113 seconds for test to complete.
Test will complete after Thu Oct  5 03:40:52 2017

During the test, I monitored its progress with smartctl --capabilities:

# watch -n 1 'echo "--- sda"; smartctl --capabilities /dev/sda | head -13 | tail -9; echo "--- sdb"; smartctl --capabilities /dev/sdb | head -13 | tail -9'

Offline data collection status:  (0x84) Offline data collection activity
                                        was suspended by an interrupting command from host.
                                        Auto Offline Data Collection: Enabled.
...
Total time to complete Offline 
data collection:            (  113) seconds.

and viewed the results when it completed:

Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
...
Total time to complete Offline 
data collection:            (  113) seconds.

The parameters were now a bit different from above:

ID#  ATTRIBUTE_NAME        VALUE WORST THRESH   WHEN_FAILED RAW_VALUE 
1    Raw_Read_Error_Rate   100  100  016    -
2    Throughput_Performa   136  136  054    -
3    Spin_Up_Time          100  100  024    -
5    Reallocated_Sector_   100  100  005    -
7    Seek_Error_Rate       100  100  067    -
8    Seek_Time_Performan   128  128  020    -
9    Power_On_Hours        100  100  000    -
10   Spin_Retry_Count      100  100  060    -
12   Power_Cycle_Count     100  100  000    -
193  Load_Cycle_Count      100  100  000    -
194  Temperature_Celsius   125  125  000    -    48   (Min/Max
197  Current_Pending_Sec   100  100  000    -
APM level is:     Disabled

(2nd Run: With the second pair of hard drives, sda's Throughput_Performance was 137 for VALUE and WORST; sdb's values matched above. Also temperature was cooler for these at 31 and 34, but that's probably because I know what I'm doing this time and breezing through these steps so they didn't heat up yet.)

It looks like the temperature is going up; it's been a couple minutes since it ended as I'm trying to capture my notes here. It was 46, then 47, now 48. The drives are sitting in the bookcase portion of a standard desk, so they're enclosed on five of six sides, but I would expect it to be warmer inside of a PC case. I turned on the ceiling fan in the room to circulate some air in case it helps.

The error log showed no errors:

# smartctl --log=error /dev/sdX
=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
No Errors Logged

Run Short Self-Test

Next, I ran the two-minute short self-test for each of sda and sdb:

# smartctl --test=short /dev/sdX

Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Thu Oct  5 04:10:34 2017

During the test, I monitored its progress with smartctl --capabilities:

# watch -n 1 'echo "--- sda"; smartctl --capabilities /dev/sda | head -13 | tail -9; echo "--- sdb"; smartctl --capabilities /dev/sdb | head -13 | tail -9'

Self-test execution status:      ( 249) Self-test routine in progress...
                                        90% of test remaining.
                                 ( 248) 80% of test remaining.
                                 ( 247) 70% of test remaining.
                                 ( 246) 60% of test remaining.
                                 ( 245) 50% of test remaining.
                                 ( 244) 40% of test remaining.
                                 ( 243) 30% of test remaining.
                                 ( 242) 20% of test remaining.
                                 ( 241) 10% of test remaining.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.

(Note: The output didn't really look like this; I combined all the different percentages for easier readability here. The long test below shows more realistic output.)

The parameters seem to not have changed at all except the temperature seems to be fluctuating between 47 and 48:

ID#  ATTRIBUTE_NAME        VALUE WORST THRESH   WHEN_FAILED RAW_VALUE 
1    Raw_Read_Error_Rate   100  100  016    -
2    Throughput_Performa   136  136  054    -
3    Spin_Up_Time          100  100  024    -
5    Reallocated_Sector_   100  100  005    -
7    Seek_Error_Rate       100  100  067    -
8    Seek_Time_Performan   128  128  020    -
9    Power_On_Hours        100  100  000    -
10   Spin_Retry_Count      100  100  060    -
12   Power_Cycle_Count     100  100  000    -
193  Load_Cycle_Count      100  100  000    -
194  Temperature_Celsius   127  127  000    -    47   (Min/Max
197  Current_Pending_Sec   100  100  000    -
APM level is:     Disabled

The self-test log showed no errors:

# smartctl --log=selftest /dev/sdX
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%         1         -

Note: The LifeTime(hours) column in the self test log can provide an indication of how long since the last test when combined with the Power_On_Hours from Attribute 9 for the current lifetime hours.

(2nd Run: LifeTime(hours) was 0 this time. Again because I'm moving faster and getting through these steps sooner this time.)

Run Conveyance Self-Test

I couldn't run this one for these devices. I tried:

# smartctl --test=conveyance /dev/sdX
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Conveyance Self-test functions not supported

Sending command: "Execute SMART Conveyance self-test routine immediately in off-line mode".
Command "Execute SMART Conveyance self-test routine immediately in off-line mode" failed: scsi error aborted command

Too bad. After reading someone else's response somewhere, I confirmed the man page stated, "identify damage incurred during transporting of the device". After receiving these via courier, I would love to have run this type of test.

Run Long/Extended Self-Test

I kicked off the last SMART test to run on these drives late at night and I won't be around to check it after 10 hours, so it'll have to wait till tomorrow night--almost 24 hours from now.

# smartctl --test=long /dev/sdX

Testing has begun.
Please wait 571 minutes for test to complete.
Test will complete after Thu Oct  5 13:57:44 2017

During the test, I periodically monitored its progress with smartctl --capabilities:

# watch -n 1 'echo ---- /dev/sda; smartctl --capabilities /dev/sda | head -13 | tail -9; echo ---- /dev/sdb; smartctl --capabilities /dev/sdb | head -13; tail -9'

---- /dev/sda
Self-test execution status:      ( 249) Self-test routine in progress...
                                        90% of test remaining.
Total time to complete Offline
data collection:                 ( 113) seconds.
---- /dev/sdb
Self-test execution status:      ( 249) Self-test routine in progress...
                                        90% of test remaining.
Total time to complete Offline
data collection:                 ( 113) seconds.
...

I came back probably about six hours after starting and observed the output indicated 10% remaining, but I knew I wouldn't be around for the completion. I did notice none of the SMART attributes seemed way out there.

I came back 24 hours after starting and confirmed the test completed:

Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.

Since the drives were idle all day, they seem to have cooled down by now:

ID#  ATTRIBUTE_NAME        VALUE WORST THRESH   WHEN_FAILED RAW_VALUE 
1    Raw_Read_Error_Rate   100  100  016    -
2    Throughput_Performa   136  136  054    -
3    Spin_Up_Time          100  100  024    -
5    Reallocated_Sector_   100  100  005    -
7    Seek_Error_Rate       100  100  067    -
8    Seek_Time_Performan   128  128  020    -
9    Power_On_Hours        100  100  000    -
10   Spin_Retry_Count      100  100  060    -
12   Power_Cycle_Count     100  100  000    -
193  Load_Cycle_Count      100  100  000    -
194  Temperature_Celsius   142  142  000    -    42   (Min/Max 23/50)
197  Current_Pending_Sec   100  100  000    -
APM level is:     Disabled

The Min/Max is cut off for some reason (probably due to a typo in the awk script above) so I manually ran smartctl --attributes and pasted in the values for the this past output. It appears the temperature reached 50 at some point.

The self-test log showed no errors:

# smartctl --log=selftest /dev/sdX
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 2  Extended offline    Completed without error       00%        10         -
# 1  Short offline       Completed without error       00%         1         -

Run badblocks

As I was running the long self-test above, I was debating whether or not I should perform this section at the same time, or wait until the self-test completes. For these first two disks, I opted to let the long self-test run to completion before formatting the partitions, so I'm writing this section while the test above runs, but I didn't run these steps until 24 hours later after the test above completed.

Note: As @Xen2050 stated, this section performs a write test on the device. I did not mind running this on my hard disk drives; however, I would think twice before running this on any flash memory or SSD due to the limited writes.

If I was going to use an ext2 or ext4 file system, I could run a command such as the following to format the partition(s) after partitioning with fdisk/gdisk:

# mke2fs -c -c /dev/sdX1

According to the man page, the first -c checks for bad blocks before creating the file system, and the second -c performs a slower read-write test.

The man page also has a warning to use the -c option rather than running badblocks directly.

However, I don't plan to put any ext file system on these drives, so I decided to run badblocks directly.

Check SMART Attributes Before Test

The temperature seems to be fluctuating between 42 and 43; otherwise, everything else is static:

ID#  ATTRIBUTE_NAME        VALUE WORST THRESH   WHEN_FAILED RAW_VALUE 
1    Raw_Read_Error_Rate   100  100  016    -
2    Throughput_Performa   136  136  054    -
3    Spin_Up_Time          100  100  024    -
5    Reallocated_Sector_   100  100  005    -
7    Seek_Error_Rate       100  100  067    -
8    Seek_Time_Performan   128  128  020    -
9    Power_On_Hours        100  100  000    -
10   Spin_Retry_Count      100  100  060    -
12   Power_Cycle_Count     100  100  000    -
193  Load_Cycle_Count      100  100  000    -
194  Temperature_Celsius   139  139  000    -    43   (Min/Max
197  Current_Pending_Sec   100  100  000    -
APM level is:     Disabled

We now have a baseline prior to the write test.

Run badblocks

Now, I was ready to run badblocks on both sda and sdb:

# time badblocks -s -v -w /dev/sdX
Checking for bad blocks in read-write mode
From block 0 to 3907018583
Testing with pattern 0xaa:   0.00% done, 0:55 elapsed. (0/0/0 errors)

As with the extended test above, I ran this on both drives simultaneously.

I came back 15-20 minutes later; the temperature is now at 46 for both drives and it looks like it's 0.02% complete.

Testing with pattern 0xaa:   0.02% done, 18:33 elapsed. (0/0/0 errors)

If I'm doing my math right, this means the test will take about 100000 minutes, or 70 days, to complete. I'm afraid I don't have that much time as I have two more drives to check and only a 30-day return/exchange period, so I'll worry about this later some time.

Check SMART Attributes After Test

I aborted the test after another 15 minutes or so. The SMART attributes were the same as above only with the temperature different.

Additional Tests

As stated, if I had the time or if the drives were smaller, I could let the write test continue to completion.

Alternatively, if I wanted to zero out the drives, I could do so with:

# dd if=/dev/zero of=/dev/sdX bs=1M

While doing so, I could monitor the SMART attributes for any drastic changes.

The drives have already been up for 24 hours per @sawdust's recommendation, and I observed the SMART attributes during this time.

(2nd Run: This is what I ended up doing for these two drives for a while.)

Repeat for Additional Drives

At this time, I powered off the drives and replaced with two additional new ones, and ran through all the steps above for them as stated earlier.

  • 2
    Executing the SMART extended test and leaving the drives powered-on for 24 hours is a simple burn-in to combat infant failures. I don't bother formatting or writing data until after burn-in. See weibull.com/hotwire/issue21/hottopics21.htm – sawdust Sep 22 '17 at 5:20
  • Thanks for the update, it looks pretty thorough! Had an idea that it's probably the USB / enclosure that's causing the glacially slow writes with badblocks, if using a direct SATA connection doesn't speed it up that's a giant red flag too. A system monitor (I like conky 1.9) should show the disk read & write speeds too. [USB never seem to run at the highest advertised speeds for me, maybe a hub or wire (or old mystery device or setting or the humidity & moon phase...?) slows everything down, or forces slow USB1 speeds] – Xen2050 Oct 23 '17 at 10:28
  • Actually it was the old computer that was the problem--Compaq Presario 5300 I believe with ancient CPU and USB ports. I moved to a Dell N500 laptop I believe and the do performance jumped 20x from around 500 KB/s to almost 10 MB/s for the first drive. – jia103 Oct 24 '17 at 1:35
  • Actually I think your should not have added the answers to the question: When browsing it for the first time I wondered: "All the solutions seem to be there already; what is he asking for?" – U. Windl Feb 7 '20 at 19:49
6
  • Most of the SMART monitoring tools will sound alerts themselves if it detects something going wrong, I think a couple to watch out for are "Current Pending Sectors" and maybe "Reallocated Sector Count", but a few errors are apparently common.

    Run all the SMART self-tests too, offline, short, long, and the conveyance test should be particularly applicable, it's "intended to identify damage incurred during transporting of the device."

    See smartctl's man page for more info, or Ubuntu's Community Help Wiki on Smartmontools

  • When formatting the drive, have it run the write testing of badblocks (or run it yourself before formatting, apparently not all mkfs's support it), it writes 0's, 1's, 01's and 10's and should be a good workout, check the SMART data afterwards too for any drastically increased numbers.

    If it's a flash memory device or an SSD you might want to keep in mind they have a limited lifetime of writes, but decent SSD's [I've read in a test] where they should handle an insane amount of writes before failing, like constant writes for months, far more than normal usage does, so don't worry.]

  • Check the drive's spindown timeout, there were some drives in the past that would spindown every 2 or 3 minutes, really wearing out the drives in record time. In linux it's usually the responsibility of other programs to time & spindown drives, but watch out for the drive itself.

  • If you can monitor the temperature of the drive, do so. hddtemp should work. One drive being significantly hotter than the others would be a red flag about the drive or just it's cooling.

And if the manufacturer has a specific testing/monitoring program, give it a try. They should have more insight into the drive's specifics.

  • The "every 2 or 3 minutes spin down" issue was an unfortunate interaction between the WD idle3 timer (mostly on "green" drives) and the way Linux handles I/O. See idle3-tools how to fix this. – dirkt Sep 22 '17 at 6:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.