Kevin OBrien

Seagate Archive HDD Review (8TB) Discussion

Recommended Posts

The Seagate Archive HDD 8TB is a high capacity, energy efficient, and lower cost hard drive for active archive purposes. The drive comes with impressive burst results but lower sustained write results, which are to be expected in this class SMR drives.

Share this post


Link to post
Share on other sites

Regrettably, they probably are. SMR has a pretty huge performance hit under certain situations, so yes.

For most end users, I think that PMR drives remain the best option.

Edited by CrazyElf

Share this post


Link to post
Share on other sites

Burst random writes are really fast, but sustained random writes are super slow (3 IOPS vs 200-230 IOPS).

Share this post


Link to post
Share on other sites

Please excuse my ignorance but I'm assuming after reading the review that it's not suited to my purpose which is to store my raw photos on. I shoot 2+ TB a year. I'll access them for editing and creating backups else where.

I have a Synology DS 1513+ with 5 x 3TB and 3 x 3Tb in the desktop and I'm after another drive.

I'm eyeing off

Seagate Archive HDD, 5TB, ST5000AS0011 or Seagate Desktop SSHD, 4TB ST4000DX001

The Archive drive in either 5 or 6 TB I should say.

​Any advice would be greatly appreciated, thanks

Share this post


Link to post
Share on other sites

This paper ( https://www.usenix.org/conference/fast15/technical-sessions/presentation/aghayev ) gives a more detailed explanation of the drive's behaviour, and especially its vulnerability to sustained random writes. If that's a significant part of what you want to use a drive for, then it's clear that this drive isn't for you. Whether this category covers "most end users" is an open question.

One interesting idea I did see floated on another forum to improve SMR's performance even further was to make it a hybrid drive, with the drive's SSD acting as the drive's persistant cache.

  • Like 1

Share this post


Link to post
Share on other sites

Please excuse my ignorance but I'm assuming after reading the review that it's not suited to my purpose which is to store my raw photos on. I shoot 2+ TB a year. I'll access them for editing and creating backups else where.

I have a Synology DS 1513+ with 5 x 3TB and 3 x 3Tb in the desktop and I'm after another drive.

I'm eyeing off

Seagate Archive HDD, 5TB, ST5000AS0011 or Seagate Desktop SSHD, 4TB ST4000DX001

The Archive drive in either 5 or 6 TB I should say.

​Any advice would be greatly appreciated, thanks

Honestly you are pretty better off going with one of the Seagate NAS Pro HDDs or a standard Desktop HDD if you stick with Seagate. Neither of those drives are great for primary storage... archive drive is really designed for backups and the SSHD won't really provide you with any benefit since your "hot data" will change with each photo you work with. Might as well go with something with nice stable

This paper ( https://www.usenix.org/conference/fast15/technical-sessions/presentation/aghayev ) gives a more detailed explanation of the drive's behaviour, and especially its vulnerability to sustained random writes. If that's a significant part of what you want to use a drive for, then it's clear that this drive isn't for you. Whether this category covers "most end users" is an open question.

One interesting idea I did see floated on another forum to improve SMR's performance even further was to make it a hybrid drive, with the drive's SSD acting as the drive's persistant cache.

SMR has always been a pickle for HDD companies since it mixes great capacity and low price, which are almost irresistible for buyers. The problem is how do you put it into an environment with the last amount of random write access. The external category fit pretty well for consumers and on the enterprise side hyper-scale for the guys with huge object stores designed to handle SMR from the ground up.

Now one thing to consider is not all SMR is equal. There are many forms of this technology that we are actually working up an article on as well. Different approaches will have a different set of strengths and weaknesses compared to the one Seagate used. Many ways to skin a cat...

Share this post


Link to post
Share on other sites

Burst random writes are really fast, but sustained random writes are super slow (3 IOPS vs 200-230 IOPS).

THREE?

I assume it's that bad only after you fill up the buffer/cache?

Share this post


Link to post
Share on other sites

Key term here would be landing zone. The HDD can only absorb about 15-25GB of writes to disk before it needs to start running garbage collection to write over sections of the drive with data already in place and move it somewhere else. That isn't a DRAM buffer/cache thing... this is part of the limitation of SMR. On an SSD they operate fast enough where random I/O is measured in thousands or tens of thousands of IOPS. On a traditional HDD where "burst" is 200-230 you can see how things grind to a halt pretty quick.

And yes, it kills random write I/O and sequential.

Share this post


Link to post
Share on other sites

Key term here would be landing zone. The HDD can only absorb about 15-25GB of writes to disk before it needs to start running garbage collection to write over sections of the drive with data already in place and move it somewhere else. That isn't a DRAM buffer/cache thing... this is part of the limitation of SMR. On an SSD they operate fast enough where random I/O is measured in thousands or tens of thousands of IOPS. On a traditional HDD where "burst" is 200-230 you can see how things grind to a halt pretty quick.

And yes, it kills random write I/O and sequential.

What are the sustained sequential write stats for this drive? I don't remember seeing any in the review. I would have thought that it would bypass the cache for such writes, writing them directly to the shingled portion of the drive (and the Skylight report certainly implied that this was a likely strategy).

Share this post


Link to post
Share on other sites

We didn't notice a drop in the synthetic sequential tests but in our Veeam test speeds dropped to 29MBs over the course of writing 400GB to the drive (look at the screenshot). Started at above 100MBs, dipped way down then came up and leveled at 29MBs.

Also saw the same behavior in the RAID rebuild.

Share this post


Link to post
Share on other sites

You show 2700 4k random write IOps for this drive. That's an order of magnitude faster than the Enterprise drive! The best 15k rpm drives barely achieve 400 IOps. There's no way this data was written to the platters at this speed and in the same way as regular drives do it. Either it's still in the cache or the drive stores those writes in a clean region, where it can aggregate them (and mark the region which should have been overwritten as unused). The former would simply be an improper measurement, whereas the latter would create fragmentation (which is cleaned up later on as garbage collection).

If the latter is actually being used I think this could be of great benefit for regular desktop users on any drive. Such usage is generally very bursty, and what really hurts are moments when HDDs come to a crawl due to random acesses. Ideally it could be a setting switchable by the user or the drive could detect sustained loads and revert to regular behaviour in such cases (otherwise the entire disk would soon be completely fragmented). I think one could call this "adapting lessons learned from SDDs to HDDs".

The drive leverages an on-drive cache (roughly 20MB) to handle inbound writes

Is this just a part of the DRAM cache? Don't regular HDDs also use this as write cache? That's the most obvious usage of this cache, despite handling file table etc.

And you're saying repeatedly that the drive doesn't perform well under sustained write activity. However, the 128k sequential tests showed a very good performance (195 MB/s read and write). At this rate they'd quickly overpower a 20 MB write cache, so this can't explain these results. Furthermore, from how I understand how the drive works, sustained writes should pose no problem whatsoever. Take a new one and fill it up to 8 TB - easy. Otherwise the full sequential speed couldn't be achieved under 128k sequential tests. It's the rewrites which hurt and trigger further internal reads and rewrites of entire shingled blocks (until the next synchronization boundary). Or am I misunderstanding something here? You may refer to your result of 30 MB/s for the full VM backup. Was this measured upon the initial backup creation, or did you overwrite an existing one? If I'm right you should adjust those passages in the article, as they would give a wrong impression of the drive.

This brings me to an interesting question: why is the RAID rebuild so slow? What is the NAS ordering the drive to do? Has the drive been formatted before the rebuild? In the worst case (from the point of view of the Archive HDD) I could imagine the NAS to scan and compare all files on both drives, in the order of the file system (creating lot's of random accesses), and then updating any differing data on the new drive (causing lot's of rewrites). Another unfavorable variant would be to copy file by file, while somehow transferring the same fragmentation which is probably present on the source drive. Again this would trigger lot's of rewrites of imcomplete shingled sections.

A version which should IMO work very well is to just copy everything, sector by sector, from the reference HDD to a formatted Archive HDD. All data would be sequential and could be grouped in large blocks, so any shingled section can be written at once, without any rewrites. I'm no NAS programmer, but this doesn't sound too hard.

@jasrockett: I do not see why you couldn't use the Archive for long term storage of your photos. You write them once and that's it. There may be a read access every now and then. And when you want to edit one you'd copy it over to your PC anyway, work on it and then transfer it back. The drive can cope with rewriting a few 10 MB's occasionally. My dad is doing it like this: one 8 TB Archive in the PC for accessible storage of the mostly static photos and an external one for mirroring according to his backup schedule. And if you're buying them: go straight for the 8TB version. At 2+ TB/year you'll need the space anyway and they're just 13% / 30€ more expensive than the 6 TB version (in Germany).

MrS

Edited by [ETA]MrSpadge

Share this post


Link to post
Share on other sites

I think the on-disk write cache is in fact 20GB (and the 20MB is just a typo). I'm also wondering if the slow RAID-rebuild/Veeam speeds are indicative of general sustained sequential write speeds, or an an artifact of some idiosyncacy of the processes involved.

Share this post


Link to post
Share on other sites

The landing zone is 20GB correct. And again as mentioned the synthetic test didn't show the sustained sequential drop but the single drive Veeam and separate RAID1 rebuild figures did. No magic there, all HDD vendors know this and will tell you as much with SMR drives.

SMR handle both random and sequential bursts as sequential writes (hence the high 4k burst figure). Once it leaves the landing zone all bets are off.

Share this post


Link to post
Share on other sites

Burst random writes are really fast, but sustained random writes are super slow (3 IOPS vs 200-230 IOPS).

How many IOPS do you get out of a 1.44 mb floppy drive? :)

Share this post


Link to post
Share on other sites

How many IOPS do you get out of a 1.44 mb floppy drive? :)

4K random accesses are quite costly on a floppy drive, because 4 KiB is almost half a track on a 1440 KiB floppy. ;)

Share this post


Link to post
Share on other sites

The product manual link with much more detail is here:

http://www.seagate.com/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/100757960c.pdf

Still wondering - and this review underlined it even more - why Seagate sells these also as single 8TB USB3 external drives.

http://www.newegg.com/Product/Product.aspx?Item=N82E16822178682

Share this post


Link to post
Share on other sites

Has someone confirmed that one of the 8TB Backup Plus units is a Seagate Archive 8TB inside?

(I agree-- seems very, very likely, but I haven't seen confirmation)

Share this post


Link to post
Share on other sites

Unless Seagate is packing those with HGST He8s, there is no other 8TB drive to use.

Share this post


Link to post
Share on other sites

The product manual link with much more detail is here:

http://www.seagate.com/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/100757960c.pdf

Still wondering - and this review underlined it even more - why Seagate sells these also as single 8TB USB3 external drives.

http://www.newegg.com/Product/Product.aspx?Item=N82E16822178682

Under single drive burst workloads they might be okay. Or at least serviceable. We will ask about getting one in.

Share this post


Link to post
Share on other sites

The landing zone is 20GB correct. And again as mentioned the synthetic test didn't show the sustained sequential drop but the single drive Veeam and separate RAID1 rebuild figures did. No magic there, all HDD vendors know this and will tell you as much with SMR drives.

SMR handle both random and sequential bursts as sequential writes (hence the high 4k burst figure). Once it leaves the landing zone all bets are off.

Thanks for your answer, Kevin. Do I understand it correctly that the landing zone is the cache described in the article and is a dedicated area on the platter(s)? Is it hidden from the user (as in SSDs), or does performance crash when one fills the last 20 GB?

OK, now I understand the high 4k scores. But I'm still wondering about sequential writes. Not rewrites, mind you. If the drive is so slow under sustained sequential write, it apparently can't write the "shingled blocks" at once. Instead it seem to be writing a part of it, then notices the next write command to the same block, reads that block again and then overwrites the 1st contents and adds the 2nd data set.

Seriously, this is rediculously stupid for sequential accesses. How large are these blocks? Considering that one only looses one single track to create a "resync" boundary between shingled blocks, those blocks can't be all that large. A few MB maybe? Certainly small enough to fit comfortably into the 128 MB onboard cache. If not: enlarge the cache a bit. DRAM is dirt cheap compared to such a 8 TB drive. Then gather sequential writes until there's enough for a full shingled segment and write it at once. The drive may cost 1-2$ more, but without the massive sequential performance hit the many new usage scenarios and possible markets are opening up for this drive. One can't fix rewrites this way, so there's still easily enough market left for the traditional drives.

MrS

Share this post


Link to post
Share on other sites

OK, now I understand the high 4k scores. But I'm still wondering about sequential writes. Not rewrites, mind you. If the drive is so slow under sustained sequential write, it apparently can't write the "shingled blocks" at once. Instead it seem to be writing a part of it, then notices the next write command to the same block, reads that block again and then overwrites the 1st contents and adds the 2nd data set.

I don't think he's saying they're slow under all sustained sequential writes ("And again as mentioned the synthetic test didn't show the sustained sequential drop"), just some of them ("but the single drive Veeam and separate RAID1 rebuild figures did"). My assumption (based on some ambiguous wording in the Skylight report) is that the drive may have the capability to bypass the cache and do sustained sequential writes directly to the shingled drive (avoiding the cache's potential bottleneck for sustained writing), but that some circumstances lead it to treat apparently-sequential data as 'random' and still use the cache.

Share this post


Link to post
Share on other sites

I don't think he's saying they're slow under all sustained sequential writes ("And again as mentioned the synthetic test didn't show the sustained sequential drop"), just some of them ("but the single drive Veeam and separate RAID1 rebuild figures did"). My assumption (based on some ambiguous wording in the Skylight report) is that the drive may have the capability to bypass the cache and do sustained sequential writes directly to the shingled drive (avoiding the cache's potential bottleneck for sustained writing), but that some circumstances lead it to treat apparently-sequential data as 'random' and still use the cache.

You need to remember though that in any scenario with the exception of a drive maybe just out of the box, no sequential write will not distrupt the data on a bordering track. So eventually things slow down because every write eventually turns into a write, read bordering track, and rewriting that track. There is no "safe" write activity that can happen anywhere except the landing zone.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now