Seagate’s first shingled hard drives now shipping: 8TB for just $260

SSD · February 3, 2015

Just got my tracking number. Should have the drive by end of day tomorrow and I'll run some benchmarks while it's in the case. In addition to that, I'll copy various sets of files from RAM to the drive and back (provided I can find a good RAMdisk program). A 10 gig file, ten 1 gig files, 10 gigs of ~5 meg files, 10 gigs of tiny files. Then a full diagnostic before I pop it out of the case. Then I can see what it gets on a fast machine connected directly to a SATA controller with the same benchmarks and file sets.

Any requests for other tests should be made before I start preclearing.

Would be interesting to time a 10G write to the drive using "dd" and then time a second write to the exact same block. This would show the performance penalty of an overwrite.

jtown · February 3, 2015

Would be interesting to time a 10G write to the drive using "dd" and then time a second write to the exact same block. This would show the performance penalty of an overwrite.

Hrm. I'm not much for linux but I think I can parse it out. dd infile, outfile, seek=...

Or just make a 10 gig partition on the 8tb drive and write to it twice.

garycase · February 3, 2015

... Or just make a 10 gig partition on the 8tb drive and write to it twice.

Probably the easiest way to guarantee the write is to the same shingled block. It would, of course, also be interesting to see the READ speeds of data from the same block.

Note that these are all likely to be from the outermost cylinders, where the drive is at its fastest ... but nevertheless it'll be an interesting test of the relative read vs. write performance.

garycase · February 3, 2015

One factor that could impact your testing -- although the theoretical speed of USB v3 is well above what this drive (or any non-SSD drive) can achieve, in real life USB v3 interfaces rarely get much above 100-150MB/s. It'll still be very useful to see the relative read and write rates you get ... but after you decide the drive is okay and extract it from the case, it would also be interesting to repeat the same tests with a direct SATA interface.

SSD · February 3, 2015

Would be interesting to time a 10G write to the drive using "dd" and then time a second write to the exact same block. This would show the performance penalty of an overwrite.

Hrm. I'm not much for linux but I think I can parse it out. dd infile, outfile, seek=...

Or just make a 10 gig partition on the 8tb drive and write to it twice.

With the seek parameter you can control the location of the write and ensure you are hitting the exact same location. You can also target whatever part of the drive. A seek value of zero would be the very outermost track. If you do this test first that would be fine. Do this before formatting the drive as the dd will destroy the format. The in file can be /dev/zero.

jtown · February 4, 2015

After several episodes of squirrel!!!, I finally sat down and got some numbers. I failed to run my test of 10 gigs of tiny files [yet] because it's going to take time to gather them and move them around. I'll save that for tomorrow or Thursday. My bad for not considering that it would take a while to stage that file group. The 8tb drive is still in the USB3 enclosure. I'm not going to pop it out until I run a full diagnostic test.

What I did do was run my huge, large, and medium write and read tests and CrystalDiskMark all on a short-stroked drive so the data would be constantly overwriting the same ~12 gig section. I saw three performance anomalies. During my single-file test writes, there were two writes significantly longer than the rest. A little over 10 seconds longer. I did extra writes to see if it would continue to increase but it didn't. The transfer times went back down to the original baseline. The second anomaly was during my read of medium sized files. The initial read took about 5 seconds longer than subsequent reads. The third anomaly showed up in CrystalDiskMark's 4k random writes. Occasionally, one of the write 4k write tests would kick back a result in the 0.5 MB/s range. Happened on both the QD=1 and QD=32 tests.

I should note that the initial 9.83 gig single file write was on a virgin drive. All I did before writing that file to the drive was shrink the partition to just under 12 gigs. It wasn't the fastest write by any measure. I also included a CrystalDiskMark report for the ImDisk RamDisk I used as a source for the write tests and destination for the read tests to show that it's not a bottleneck.

Write 9.83 gigabyte file

1:37

1:33

1:34

1:48

1:51

1:33

1:35

1:34

1:35

Write 9.33 gigabyte group of 8 files

1:43

1:50

1:46

1:36

1:45

Write 9.72 gigabyte group of 432 files

1:46

1:43

1:42

Read 9.83 gigabyte file

1:02

1:03

1:04

1:05

Read 9.33 gigabyte group of 8 files

1:01

0:59

Read 9.72 gigabyte group of 432 files

1:10

1:03

1:05

1:04

1:05

-----------------------------------------------------------------------

Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 byte/s [sATA/300 = 300,000,000 byte/s]

Sequential Read : 177.057 MB/s

Sequential Write : 118.849 MB/s

Random Read 512KB : 49.534 MB/s

Random Write 512KB : 89.007 MB/s

Random Read 4KB (QD=1) : 0.595 MB/s [ 145.2 IOPS]

Random Write 4KB (QD=1) : 13.572 MB/s [ 3313.5 IOPS]

Random Read 4KB (QD=32) : 0.658 MB/s [ 160.7 IOPS]

Random Write 4KB (QD=32) : 13.184 MB/s [ 3218.6 IOPS]

Test : 4000 MB [F: 3.2% (0.4/11.6 GB)] (x9)

Date : 2015/02/03 23:38:21

OS : Windows 7 Ultimate SP1 [6.1 Build 7601] (x64)

-----------------------------------------------------------------------

Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 byte/s [sATA/300 = 300,000,000 byte/s]

Sequential Read : 5136.931 MB/s

Sequential Write : 6893.991 MB/s

Random Read 512KB : 4967.123 MB/s

Random Write 512KB : 6610.360 MB/s

Random Read 4KB (QD=1) : 626.017 MB/s [152836.2 IOPS]

Random Write 4KB (QD=1) : 564.216 MB/s [137748.2 IOPS]

Random Read 4KB (QD=32) : 1113.794 MB/s [271922.4 IOPS]

Random Write 4KB (QD=32) : 980.928 MB/s [239484.3 IOPS]

Test : 4000 MB [J: 0.8% (0.1/10.0 GB)] (x9)

Date : 2015/02/03 23:15:15

OS : Windows 7 Ultimate SP1 [6.1 Build 7601] (x64)

jtown · February 6, 2015

My read tests of an 8.30 gigabyte group of 415,535 files were all over the place so I'm assuming there's something wrong with my test method. Despite clearing buffer and cache between tests, I got times ranging from 30:00 to 5:41. The writes were pretty consistent.

Write 8.30 gigabyte group of 415,535 files

29:51

23:21

23:39

20:01

26:21

Read 8.30 gigabyte group of 415,535 files

30:00

9:46

8:04

18:33

6:08

5:42

5:41

5:43

5:41

5:43

jtown · February 6, 2015

After removing the drive from its enclosure and connecting it to my SATA/600 controller, the first thing I noticed is that the 12 gig partition I'd been using was not present. Windows informed me that I'd need to format the new drive. Seemed odd so I fired up disk management and there was a raw partition under 2 gigs at the beginning of the drive. No sign of the partition I'd been using for testing. I expanded it to 12 gigs and formatted it without incident. Other than the whole having to do all that. That's a bit of an incident.

I'm not sure what this means. Does the USB->SATA adapter in the enclosure act as some sort of intermediary, optimizing drive access? But, if it does, how could it keep track of 8tb of remapping? Or maybe my controller isn't able to handle an 8tb drive. Seems unlikely, tho, as it shows the correct total capacity (adjusted for inflation) of 7452.04 GB. Seems like the controller and OS are both recognizing the full drive capacity. And I had no trouble recreating the partition and using it for testing.

Anyway, I've done most of the same tests with the drive connected to a SATA port and some of it is surprising. Writing the single large file takes a bit longer. Writing the "8 file" set and the "432 file" set were slightly faster. Writing the "415,535 file" set is taking dramatically longer. It's on track to take about two and a quarter hours. Way up from the 20-30 minutes when the drive was in the USB enclosure. The read tests were very surprising. Throughput was way down across the board. An extra 30 seconds on the single file, an extra minute on the "8 file" set, an extra two minutes on the "432 file" set. Haven't had a chance to do the read test on the gigantic set of files because the write test is still in progress. I'm almost afraid to try it because, if these trends continue, that set could take infinity-1 to read.

CrystalDiskMark shows a noticeable increase in write speeds in the sequential write and 512k random write tests. Random 4k tests are similar except for the 4k QD=32 write test which is significantly slower.

All in all, the results of bare drive testing were not what I expected.

Write 9.83 gigabyte file

2:06

1:50

1:45

1:43

1:49

Write 9.33 gigabyte group of 8 files

1:13

1:10

1:11

1:17

1:11

Write 9.72 gigabyte group of 432 files

1:05

1:04

1:06

1:07

1:10

Write 8.30 gigabyte group of 415,535 files

Incomplete

Read 9.83 gigabyte file

1:30

1:26

1:22

1:18

1:14

Read 9.33 gigabyte group of 8 files

2:34

2:32

2:31

2:21

2:10

Read 9.72 gigabyte group of 432 files

3:00

2:50

2:40

2:28

2:17

Read 8.30 gigabyte group of 415,535 files

Incomplete

-----------------------------------------------------------------------

Crystal Dew World : http://crystalmark.info/

-----------------------------------------------------------------------

* MB/s = 1,000,000 byte/s [sATA/300 = 300,000,000 byte/s]

Sequential Read : 159.431 MB/s

Sequential Write : 164.935 MB/s

Random Read 512KB : 52.429 MB/s

Random Write 512KB : 110.324 MB/s

Random Read 4KB (QD=1) : 0.568 MB/s [ 138.8 IOPS]

Random Write 4KB (QD=1) : 12.410 MB/s [ 3029.8 IOPS]

Random Read 4KB (QD=32) : 1.736 MB/s [ 423.8 IOPS]

Random Write 4KB (QD=32) : 0.847 MB/s [ 206.8 IOPS]

Test : 4000 MB [D: 0.7% (0.1/11.9 GB)] (x9)

Date : 2015/02/05 22:09:36

OS : Windows 7 Ultimate SP1 [6.1 Build 7601] (x64)

garycase · February 6, 2015

VERY strange that the partition was missing. Did Windows require initialization ... or just formatting?

Now that the drive's out of the enclosure, is it the standard ST8000AS0002 Archive Drive that Seagate's marketing for internal use? [Just curious if they modified the model # for their external units]

pkn · February 6, 2015

Write 9.83 gigabyte file

2:06

1:50

1:45

1:43

1:49

Thanks, jtown! That's essentially one number I'm really interested in. So it translates to writing speed about 80-90 MB/sec. Not so bad as I was afraid of. I think this drive has great future in many unRAID arrays... including one of mine

jtown · February 6, 2015

VERY strange that the partition was missing. Did Windows require initialization ... or just formatting?

Now that the drive's out of the enclosure, is it the standard ST8000AS0002 Archive Drive that Seagate's marketing for internal use? [Just curious if they modified the model # for their external units]

The label says Archive HDD, ST8000AS0002, PN 1NA17Z-568, FW AR13

I'm maybe 68% certain it said format. Not nearly certain enough to bet my life. When I do a data drive, I'll plan better by making sure my firmware and drivers are all up to date and make better notes. The next one won't be repartitioned before I mess with it.

jtown · February 6, 2015

Finally did the write/read tests of my set of 415,535 files. Write was 2:31. That's 2 hours, 31 minutes. Read was 24:27. 24 minutes, 27 seconds. Just one run each. I'm not going to spend another 10 hours getting 4 more write tests. Time to preclear.

pkn · February 6, 2015

Just FYI, from chat with Seagate representative:

Q: -- What is the exact capacity, in bytes, of this drive?

A: -- The only information I can find is the number of guaranteed sectors. Using the sectors I can say the number of guaranteed bytes should be 8,001,563,222,016. Since normally 512 bytes are located in 1 sector.

Q: -- So documentation guarantees at least 15,628,053,168 sectors? Could there be a significant number of... I dont know... "extra" sectors?

A: -- Yes.

P.S. Sorry for crossposting... :-*

garycase · February 6, 2015

... the number of guaranteed bytes should be 8,001,563,222,016

This is likely the right number, since it correlates perfectly with what jtown noted r.e. drive size ... i.e. (8,001,563,222,016) / [(1024)^3] = 7452.04 GB

Jtown => can you confirm the exact byte count next time it's convenient?

... r.e. the write speeds => These are actually looking pretty good considering the overhead involved within the drive. Certainly not comparable to a good high-density PMR drive; but it certainly looks promising as an UnRAID data drive.

jtown · February 6, 2015

Preclear says 8,001,563,222,016. 13% of the way thru the pre-read going around 165 MB/s.

garycase · February 6, 2015

Preclear says 8,001,563,222,016. 13% of the way thru the pre-read going around 165 MB/s.

Thanks ... looks like that's the number for 8TB drives then, as the manufacturer's are generally perfectly consistent with the various sizes.

jtown · February 15, 2015

The preclear cycles finally finished. A little over 67 hours per cycle. I completed 1 cycle then there was a power burp and I had to start over for the last two. Yes, I know...UPS UPS UPS. It's in the array processing parity at about 44 MB/s. If these trends continue, that speed should bump up when the creaky old 2tb drives are done and only the 4tb data drives are left.

========================================================================1.15

== invoked as: ./preclear_disk.sh -c 2 /dev/sdc

== ST8000AS0002-1NA17Z Z8400VJ7

== Disk /dev/sdc has been successfully precleared

== with a starting sector of 1

== Ran 2 cycles

==

== Using :Read block size = 8388608 Bytes

== Last Cycle's Pre Read Time : 18:19:52 (121 MB/s)

== Last Cycle's Zeroing time : 16:58:56 (130 MB/s)

== Last Cycle's Post Read Time : 41:19:33 (53 MB/s)

== Last Cycle's Total Time : 58:23:39

==

== Total Elapsed Time 134:48:44

==

== Disk Start Temperature: 38C

==

== Current Disk Temperature: 37C,

==

============================================================================

** Changed attributes in files: /tmp/smart_start_sdc /tmp/smart_finish_sdc

ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE

Raw_Read_Error_Rate = 119 118 6 ok 203428856

Seek_Error_Rate = 79 77 30 ok 91686090

Spin_Retry_Count = 100 100 97 near_thresh 0

End-to-End_Error = 100 100 99 near_thresh 0

Airflow_Temperature_Cel = 63 62 45 In_the_past 37

Temperature_Celsius = 37 38 0 ok 37

Hardware_ECC_Recovered = 119 118 0 ok 203428856

No SMART attributes are FAILING_NOW

0 sectors were pending re-allocation before the start of the preclear.

0 sectors were pending re-allocation after pre-read in cycle 1 of 2.

0 sectors were pending re-allocation after zero of disk in cycle 1 of 2.

0 sectors were pending re-allocation after post-read in cycle 1 of 2.

0 sectors were pending re-allocation after zero of disk in cycle 2 of 2.

0 sectors are pending re-allocation at the end of the preclear,

the number of sectors pending re-allocation did not change.

0 sectors had been re-allocated before the start of the preclear.

0 sectors are re-allocated at the end of the preclear,

the number of sectors re-allocated did not change.

============================================================================

garycase · February 15, 2015

... It's in the array processing parity at about 44 MB/s.

Is this a parity sync or a parity check?

It'd be interesting to know the time/avg speed for each of those.

... and also the specific configuration of the system [# and type of drives]

jtown · February 15, 2015

Sync. Can't do a check until parity exists.

Motherboard is a Supermicro X7SPA-H (6 SATA2 ports) with a Supermicro AOC-SASLP-MV8 adding 8 ports. Drives are:

Connected to motherboard

8tb ST8000AS0002

4tb ST4000DM000

4tb WDC_WD40EZRX

2tb ST32000542AS

Connected to MV8

4tb WDC_WD40EZRX

2tb HDS5C3020ALA632 (Hitachi)

2tb HD204UI (Samsung)

2tb WDC_WD20EARS

2tb WDC_WD20EARX

jtown · February 16, 2015

As I expected, the speed took a big jump when the 2tb drives finished.

Total size: 8 TB

Current position: 2.03 TB (25%)

Estimated speed: 108.29 MB/sec

Estimated finish: 919 minutes

garycase · February 16, 2015

As I'm sure you know, that's normal -- what will be even more interesting is to see what the speed is when it passes the 4TB point and the 8TB drive is the only one involved in the sync. Then we'll see the actual write speed of the drive

pkn · February 16, 2015

The preclear cycles finally finished. A little over 67 hours per cycle. ...

Good to know, thanks...

[venting mode on]

The UPS/USPS guys managed to lose the 8TB external I bought from NeweggBusiness. Or maybe they simply stole it. Tracking says it was delivered four days ago, but it actually was not. Drat, I live at this address for five years, hundreds of mail orders, and this is first time I've got into such situation, and it happened with delivery I was so much waiting for... $:-\$

[venting mode off]

jtown · February 16, 2015

As I'm sure you know, that's normal -- what will be even more interesting is to see what the speed is when it passes the 4TB point and the 8TB drive is the only one involved in the sync. Then we'll see the actual write speed of the drive

Yeah, it got another speed bump. Unfortunately, I was asleep at the 50% mark which was probably the fastest point. It's doing around 140 MB/s now. I'll try to be around when it hits 99.9ish to see what it gets there but, from what I've seen so far, it's looking pretty good.

Total size: 8 TB

Current position: 5.81 TB (73%)

Estimated speed: 140.39 MB/sec

Estimated finish: 260 minutes

garycase · February 16, 2015

From the speeds you're seeing, it seems write speeds on these drives aren't as much an issue as it would have seemed they would be. It appears that whatever technical mitigations were made to minimize write issues work very well. The unknown, of course, is how well these work when the writes are more random -- a parity sync clearly does a sequential write that covers the entire disk, unlike the random writes that normal use of the array will do. Nevertheless, it seems that this drive may work just fine even as a parity drive -- which would be very good news indeed !!

NAS · February 16, 2015

which would be very good news indeed !!

For me the 6TB WD RED is almost 48% more expensive per TB than this seagate. Thats the biggest price differential I have ever seen in the consumer sector especially when its launhc where drives typically are at their most expensive.

Seagate’s first shingled hard drives now shipping: 8TB for just $260

Recommended Posts

Link to comment

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Posted Images

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Join the conversation