10 x Hitachi 3TB 7200RPM 6Gb/s 3.5" SAS Hard Drive HUS723030ALS640 for $270 or $27/HDD

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

fake-name

Active Member
Feb 28, 2017
180
144
43
73
All 4 I got have 0 uncorrectable errors. Maybe I got lucky?

Interestingly, 3 of the 4 disks I have had been written to more then they'd been read. Maybe these disks had been a log disk.

Also of note: All 4 drives had long SMART self-tests about 10 power-on hours before they were resold. Maybe the vendor did actually test them.

Code:
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-31-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HITACHI
Product:              H7230AS60SUN3.0T
Revision:             A6C0
Compliance:           SPC-4
User Capacity:        3,000,592,982,016 bytes [3.00 TB]
Logical block size:   512 bytes
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      <snip>
Serial number:        <snip>
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Thu Jan  3 21:13:32 2019 PST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     29 C
Drive Trip Temperature:        85 C

Manufactured in week 30 of year 2012
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  7
Specified load-unload count over device lifetime:  600000
Accumulated load-unload cycles:  2124
Elements in grown defect list: 0

Vendor (Seagate) cache information
  Blocks sent to initiator = 44571645028859904

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0    56314         0     56314    2985205      27175.638           0
write:         0  2258605         0   2258605     342011     224388.337           0
verify:        0        0         0         0     125758          0.000           0

Non-medium error count:        1

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                   -   50974                 - [-   -    -]

Long (extended) Self Test duration: 27182 seconds [453.0 minutes]

smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-31-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HITACHI
Product:              H7230AS60SUN3.0T
Revision:             A310
Compliance:           SPC-4
User Capacity:        3,000,592,982,016 bytes [3.00 TB]
Logical block size:   512 bytes
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      <snip>
Serial number:        <snip>
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Thu Jan  3 21:13:32 2019 PST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     26 C
Drive Trip Temperature:        85 C

Manufactured in week 13 of year 2012
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  7
Specified load-unload count over device lifetime:  600000
Accumulated load-unload cycles:  2148
Elements in grown defect list: 0

Vendor (Seagate) cache information
  Blocks sent to initiator = 40839060717043712

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0    39234         0     39234    2065490      24099.475           0
write:         0  9142145         0   9142145    1296426      86137.917           0
verify:        0        0         0         0     511496          0.000           0

Non-medium error count:        1

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                   -   52958                 - [-   -    -]

Long (extended) Self Test duration: 27182 seconds [453.0 minutes]

smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-31-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HITACHI
Product:              H7230AS60SUN3.0T
Revision:             A6C0
Compliance:           SPC-4
User Capacity:        3,000,592,982,016 bytes [3.00 TB]
Logical block size:   512 bytes
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      <snip>
Serial number:        <snip>
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Thu Jan  3 21:13:32 2019 PST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     27 C
Drive Trip Temperature:        85 C

Manufactured in week 29 of year 2012
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  5
Specified load-unload count over device lifetime:  600000
Accumulated load-unload cycles:  2121
Elements in grown defect list: 0

Vendor (Seagate) cache information
  Blocks sent to initiator = 43919510045982720

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0    30937         0     30937    3037438      27220.281           0
write:         0  2466713         0   2466713     558461     223912.048           0
verify:        0        0         0         0      54471          0.000           0

Non-medium error count:        1

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                   -   50905                 - [-   -    -]

Long (extended) Self Test duration: 27182 seconds [453.0 minutes]

smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-31-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HITACHI
Product:              H7230AS60SUN3.0T
Revision:             A6C0
Compliance:           SPC-4
User Capacity:        3,000,592,982,016 bytes [3.00 TB]
Logical block size:   512 bytes
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      <snip>
Serial number:        <snip>
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Thu Jan  3 21:13:33 2019 PST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     26 C
Drive Trip Temperature:        85 C

Manufactured in week 06 of year 2012
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  43
Specified load-unload count over device lifetime:  600000
Accumulated load-unload cycles:  2058
Elements in grown defect list: 0

Vendor (Seagate) cache information
  Blocks sent to initiator = 55665574444793856

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0  4306125         0   4306125   22265366    2465468.877           0
write:         0 10255202         0  10255202    3344293    1526649.887           0
verify:        0        1         0         1     425510         23.243           0

Non-medium error count:        1

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                   -   55929                 - [-   -    -]

Long (extended) Self Test duration: 27182 seconds [453.0 minutes]
 

james23

Active Member
Nov 18, 2014
441
122
43
52
interesting, thanks.

i think that smart test was the previous owner doing that smart test, and then saying yep this is a drive we need to replace (for whatever reason), and then it somehow the drive made its way to our ebay seller. (just a guess/ half joking)

i only say that bc all 10x of mine only had 1x smart tests run , and that was in the first 1-4 POH , and none since (ie when the drive was brand new).

so far my 10x have been stressing for about 5 hours, no issues or errors so far! cant beat this price too (22.5$ each)
 

wildpig1234

Well-Known Member
Aug 22, 2016
2,197
443
83
49
I got ten of the 4TB sas ones for $470 so not quite as cheap per TB but they would last me for over 2 yrs of archival purpose.... It's kinda crazy to see these used HDD price is cheaper than BD-R price. i guess i will see how long they will last as archival purpose. I take them out and place them into storage as soon as one is filled to minimize wear and tear. They are written to only once by me...

It saves me a lot of time now that i don't have to do BD layout before burning the disc anymore. Now it's direct copy to the HDD and then just remove and store... faster write speed too.
 

james23

Active Member
Nov 18, 2014
441
122
43
52
depending on how long you plan on keeping these disks (ie if for 10+ years) you may want to buy and stick a sata to USB adapter in your storage box. just incase the interface is hard to find adapters for in 10,20,30 yrs from now. (doubtful, but i know people that do this for long term archive purposes)

fwiw, i had burned some data (mp4 video), ntfs volume, on to tayo yuden gold archival DVD-R media about 12 years ago, and was able to read it back just fine recently. I did add par2 files to the dvds (and a separate dvd with only par2 files from all the dvds). but the video played back fine. I think video (and watching the video), is a decent way to easily see if your archive has had any data degradation over time, as you will visually see the issues (or video wont play). ofcourse par files, or good checksum files can serve the same purpose of quickly/easly verifying integrity.
(btw its a bit harder to find a pc dvd drive nowadays than 12 yrs ago)
 

wildpig1234

Well-Known Member
Aug 22, 2016
2,197
443
83
49
depending on how long you plan on keeping these disks (ie if for 10+ years) you may want to buy and stick a sata to USB adapter in your storage box. just incase the interface is hard to find adapters for in 10,20,30 yrs from now. (doubtful, but i know people that do this for long term archive purposes)

fwiw, i had burned some data (mp4 video), ntfs volume, on to tayo yuden gold archival DVD-R media about 12 years ago, and was able to read it back just fine recently. I did add par2 files to the dvds (and a separate dvd with only par2 files from all the dvds). but the video played back fine. I think video (and watching the video), is a decent way to easily see if your archive has had any data degradation over time, as you will visually see the issues (or video wont play). ofcourse par files, or good checksum files can serve the same purpose of quickly/easly verifying integrity.
(btw its a bit harder to find a pc dvd drive nowadays than 12 yrs ago)
My first ever cd-r i burned back in 1995 still works fine. When i was using cd-r then dvd-r then finally bd-r for archival, i would burn the disc and then use another drive to copy all the files off the disc for testing. sometimes you got an error free burn but you are not able to read the disc after burn so this would ensure no read error to start with. Watching a video or listening to audio file takes too long to test and not good enough to test all the data. granted you could have maybe some subtle bit change that somehow past through both the burning and the read verify but a lot less likely.

I have a sata usb dock but i only have 2 sata hdd archive volume before discovering the much cheaper used enterprise SAS hdd.. there is currently no usb sas dock i know of unfortunately.... let me know if you see one...lol...

The used enterprise SAS HDD as back up is a little more fragile that BD-R but they are so much more efficient and is significantly cheaper and less time consuming when compared to generic BD-R... Also take a lot less room and space and weight for a given number of TB. I think it could even be cheaper than tape when factoring in the tape drive cost? also no random access with tape...

$270/30TB or $0.009/GB is significantly cheaper than $0.012/GB for $15/generic 25GB BD-R. The most significant factor is actually the HUGE amount of time i don't have to waste anymore to to the layout for each bd-r to be burned.
 
Last edited:

frogtech

Well-Known Member
Jan 4, 2016
1,482
272
83
35
I have 8 of these plugged in to a SAS controller, they show up in the SAS option ROM but not in unraid...possibility these are formatted for some kind of netapp enclosure or some other BS? Mind you I got mine from a different seller. Kind of annoying. Having to format these back is always such a huge waste of TIME.
 
Last edited:

fake-name

Active Member
Feb 28, 2017
180
144
43
73
OK, I have a weird issue here.

Of the 4 drives I've got, 2 of them are fine. Badblocks runs through them at ~150MBps, and long smart checks are also fine.

The other two seem fine normally. They pass long smart tests, show no reallocated sectors, but when I run badblocks on them they only go ~7MBps.

Strangely, if I access the disks any other way
Code:
sudo dd if=/dev/zero of=/dev/disk/by-id/scsi-35000cca01a58a7bc conv=fdatasync bs=384k count=10k
or
Code:
sudo fio --name TEST --eta-newline=5s --filename=/dev/disk/by-id/scsi-35000cca01a58a7bc --rw=randrw --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
the disks are fine, and read/write at 150MBPS.

If I increase the block size in badblocks, e.g.
Code:
sudo badblocks -wsv /dev/disk/by-id/scsi-35000cca01a58a7bc -b 65536[CODE]) or the number of blocks at a time [CODE]-e 256
, it goes faster, with
Code:
-b 65536 -c 256
it manages the full 150MBps.

I'm not sure what's going on. It seems like 2 of the disks have different IO scheduling or something. Has anyone else seen anything like this?
 

frogtech

Well-Known Member
Jan 4, 2016
1,482
272
83
35
What kind of power on hours are you finding with yours?

Also, my disks are full of:

SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Default Self test in progress ... - NOW - [- - -]
# 2 Default Self test in progress ... - NOW - [- - -]
# 3 Default Self test in progress ... - NOW - [- - -]
# 4 Default Self test in progress ... - NOW - [- - -]
# 5 Default Self test in progress ... - NOW - [- - -]
# 6 Default Self test in progress ... - NOW - [- - -]
# 7 Default Self test in progress ... - NOW - [- - -]
# 8 Default Self test in progress ... - NOW - [- - -]
# 9 Default Self test in progress ... - NOW - [- - -]
#10 Default Self test in progress ... - NOW - [- - -]
#11 Default Self test in progress ... - NOW - [- - -]
#12 Default Self test in progress ... - NOW - [- - -]
#13 Default Self test in progress ... - NOW - [- - -]
#14 Default Self test in progress ... - NOW - [- - -]
#15 Default Self test in progress ... - NOW - [- - -]
#16 Default Self test in progress ... - NOW - [- - -]
#17 Default Self test in progress ... - NOW - [- - -]
#18 Default Self test in progress ... - NOW - [- - -]
#19 Default Self test in progress ... - NOW - [- - -]

in the smart logs. Is this anything to be concerned about? Why isn't there output for these self tests and why was the status never completed?
 

fake-name

Active Member
Feb 28, 2017
180
144
43
73
#11 Default Self test in progress ... - NOW - [- - -]
That is what I get when I have a smart test actively running. Once it finishes, the "NOW" should be replaced with the power-on hours when the smart test actually ran.

Anyways, the disks I have show ~51000 to 55000 hours on-time, so 5-6 years, though only 10-50 start/stop cycles over that time.
 

czl

New Member
May 14, 2016
25
4
3
When I had this problem it turned out to be a difference in the HDD firmware write cache setting. Dump the settings (I believe the linux tool for SAS HDD's is sdparm and for SATA HDD's is hdparm) and you will likely see that the slower drives have write cache disabled. sdparm/hdparm can also change this setting and to make the change persist across reboots (I think these are two separate settings one to change it one to make it persist). I think most new HDD's are shipped with write cache enabled to max their performance and likely you want the write cache enabled as well or at least make this setting the same for all drives in the same RAID/RAIDZ array to avoid having some drives in the array be ahead of others (write cache enabled ones would be missing some data) in a power loss situation. I'm not sure how RAID/RAIDZ would handle that during recovery. Best to avoid it.

OK, I have a weird issue here.

Of the 4 drives I've got, 2 of them are fine. Badblocks runs through them at ~150MBps, and long smart checks are also fine.

The other two seem fine normally. They pass long smart tests, show no reallocated sectors, but when I run badblocks on them they only go ~7MBps.

Strangely, if I access the disks any other way
Code:
sudo dd if=/dev/zero of=/dev/disk/by-id/scsi-35000cca01a58a7bc conv=fdatasync bs=384k count=10k
or
Code:
sudo fio --name TEST --eta-newline=5s --filename=/dev/disk/by-id/scsi-35000cca01a58a7bc --rw=randrw --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
the disks are fine, and read/write at 150MBPS.

If I increase the block size in badblocks, e.g.
Code:
sudo badblocks -wsv /dev/disk/by-id/scsi-35000cca01a58a7bc -b 65536[CODE]) or the number of blocks at a time [CODE]-e 256
, it goes faster, with
Code:
-b 65536 -c 256
it manages the full 150MBps.

I'm not sure what's going on. It seems like 2 of the disks have different IO scheduling or something. Has anyone else seen anything like this?
 
Last edited:

fake-name

Active Member
Feb 28, 2017
180
144
43
73
When I had this problem it turned out to be a difference in the HDD firmware write cache setting. Dump the settings (I believe the linux tool for SAS HDD's is sdparm and for SATA HDD's is hdparm) and you will likely see that the slower drives have write cache disabled. sdparm/hdparm can also change this setting and to make the change persist across reboots (I think these are two separate settings one to change it one to make it persist). I think most new HDD's are shipped with write cache enabled to max their performance and likely you want the write cache enabled as well or at least make this setting the same for all drives in the same RAID/RAIDZ array to avoid having some drives in the array be ahead of others (write cache enabled ones would be missing some data) in a power loss situation. I'm not sure how RAID/RAIDZ would handle that during recovery. Best to avoid it.

Ohhh, bingo:

Code:
durr@auxnas:~⟫ sudo sdparm /dev/sda
    /dev/sda: HITACHI   H7230AS60SUN3.0T  A6C0
Read write error recovery mode page:
  AWRE        1  [cha: y, def:  1, sav:  1]
  ARRE        1  [cha: y, def:  1, sav:  1]
  PER         1  [cha: y, def:  1, sav:  1]
Caching (SBC) mode page:
  WCE         1  [cha: y, def:  0, sav:  1]
  RCD         0  [cha: y, def:  0, sav:  0]
Control mode page:
  SWP         0  [cha: n, def:  0, sav:  0]
Informational exceptions control mode page:
  EWASC       1  [cha: y, def:  1, sav:  1]
  DEXCPT      0  [cha: y, def:  0, sav:  0]
  MRIE        6  [cha: y, def:  4, sav:  6]
durr@auxnas:~⟫ sudo sdparm /dev/sdb
    /dev/sdb: HITACHI   H7230AS60SUN3.0T  A6C0
Read write error recovery mode page:
  AWRE        1  [cha: y, def:  1, sav:  1]
  ARRE        1  [cha: y, def:  1, sav:  1]
  PER         1  [cha: y, def:  1, sav:  1]
Caching (SBC) mode page:
  WCE         0  [cha: y, def:  0, sav:  0]
  RCD         0  [cha: y, def:  0, sav:  0]
Control mode page:
  SWP         0  [cha: n, def:  0, sav:  0]
Informational exceptions control mode page:
  EWASC       1  [cha: y, def:  1, sav:  1]
  DEXCPT      0  [cha: y, def:  0, sav:  0]
  MRIE        4  [cha: y, def:  4, sav:  4]
durr@auxnas:~⟫ sudo sdparm /dev/sdc
    /dev/sdc: HITACHI   H7230AS60SUN3.0T  A6C0
Read write error recovery mode page:
  AWRE        1  [cha: y, def:  1, sav:  1]
  ARRE        1  [cha: y, def:  1, sav:  1]
  PER         1  [cha: y, def:  1, sav:  1]
Caching (SBC) mode page:
  WCE         1  [cha: y, def:  0, sav:  1]
  RCD         0  [cha: y, def:  0, sav:  0]
Control mode page:
  SWP         0  [cha: n, def:  0, sav:  0]
Informational exceptions control mode page:
  EWASC       1  [cha: y, def:  1, sav:  1]
  DEXCPT      0  [cha: y, def:  0, sav:  0]
  MRIE        6  [cha: y, def:  4, sav:  6]
durr@auxnas:~⟫ sudo sdparm /dev/sdd
    /dev/sdd: HITACHI   H7230AS60SUN3.0T  A310
Read write error recovery mode page:
  AWRE        1  [cha: y, def:  1, sav:  1]
  ARRE        1  [cha: y, def:  1, sav:  1]
  PER         1  [cha: y, def:  1, sav:  1]
Caching (SBC) mode page:
  WCE         0  [cha: y, def:  0, sav:  0]
  RCD         0  [cha: y, def:  0, sav:  0]
Control mode page:
  SWP         0  [cha: n, def:  0, sav:  0]
Informational exceptions control mode page:
  EWASC       1  [cha: y, def:  1, sav:  1]
  DEXCPT      0  [cha: y, def:  0, sav:  0]
  MRIE        6  [cha: y, def:  4, sav:  6]
Code:
  WCE         1  [cha: y, def:  0, sav:  1]

  WCE         0  [cha: y, def:  0, sav:  0]

  WCE         1  [cha: y, def:  0, sav:  1]

  WCE         0  [cha: y, def:  0, sav:  0]
Two of the drives have the writeback cache disabled.

Also, *one* drive has a different MRIE, which is interesting. I set it to 6 like the others.

Thanks! I wasn't sure where to start looking for this kind of thing.

------

Once the badblocks scan I've got running finishes, I can check if this fixes the throughput issue.


EDIT:

Yep, the write caching change fixed it.
 
Last edited: