HDD break-in/testing
Posted: Wed Dec 20, 2023 8:32 am
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.
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.
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.
Code: Select all
#!/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}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.