Kevin OBrien

Seagate Archive HDD Review (8TB) Discussion

Recommended Posts

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.

Surely that would only happen if the drive got heavily fragmented, or almost full? On a reasonably unfragmented drive, that has a reasonable amount of free space, the majority of free space should consist of wholly-unwritten shingled-blocks, shouldn't it? All writes would only result in rewrites if all blocks are partially written -- I suppose that this would be possible with a very large number of very small files and very poor garbage collection, but in reality?

Share this post


Link to post
Share on other sites

Maybe but in two scenarios pushing real data to the drive, we saw "burst" action for a while and then a huge downturn as the drive had to shuffle things around in the background.

Share this post


Link to post
Share on other sites

Maybe but in two scenarios pushing real data to the drive, we saw "burst" action for a while and then a huge downturn as the drive had to shuffle things around in the background.

So if the "no 'safe' write activity that can happen anywhere except the landing zone" scenario inevitably happens for sustained sequential writes, then how does the synthetic test avoid this? If the synthetic test avoids it, then avoidance must be at least possible, and the question becomes is avoidance the rule or the exception?

Share this post


Link to post
Share on other sites

I might need to rework the particular test. It was originally designed for PMR drives and either its getting some form of locality or it wasn't running long enough.

Share this post


Link to post
Share on other sites

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.

Unless an entire shingled block is overwritten at once. If this happens one can disregard its current contents immediately and happily write the new ones. As in your tests, we're talking about 100's of GB here, which shall all be written sequentially. If there is so much free space on the drive left, then there have to be many entire blocks which are still "clean / safe". The OS is doing defragmentation and the drive is doing garbage collection in the background for a reason (and I like to think they achieve somethingby doing that).

This is even more evident in the case of the RAID rebuild: why should there be any dirty / unsafe blocks? Simply wipe the drive prior to the rebuild (well, the NAS software should do this itself).

From everything that is being said here I see no reason why this couldn't be done. Apparently it's not being done, as your measurements say, but until convinced otherwise I remain convinced that whatever happens there appears to be extremely stupid. Or is some important aspect of how SMR works still missing?

MrS

Share this post


Link to post
Share on other sites

I have heard of SMR tech in the works that can differentiate between RAID rebuild or init activities vs real data movement, but I'm not sure its hit the shelves yet.

Share this post


Link to post
Share on other sites

Oddball question, and potential quick-and-dirty way to see if large sequential writes bypass the cache -- what happens when you attempt to write a single file, that is larger than the cache (e.g. a bluray disk image), to the disk? This should force the drive to show its true colours, and give little opportunity to mistake sequential data for random. I would also expect that backing up large numbers of largish disk images would be a valid use-scenario for a very large archive disk (meaning that if it gets indigestion doing this, it's got some problems for its core business).

Edited by Hrafn

Share this post


Link to post
Share on other sites

HDtune besides being a terrible benchmark, is only measuring burst data skipping across sections of the drive. IE it didn't read or write 8TB of data while it ran that test. So the drive treated it as it would any other burst write and stayed inside the landing zone.

Share this post


Link to post
Share on other sites

That HDTune benchmark is also somewhat interesting: your test shows a maximum sequential write speed of 190 MB/s, which matches the read speed and the data sheet. However, overclockers.at show a constant write speed of 150 MB/s over a large capacity range. This is unphysical for a HDD, except if it was limited by the interface (it's not). Or, as Brian said, the drive would actually be writing to the reserved landing zone all the time. Can we conclude form this that the landing zone is not at the beginning of the platters, but further in? At the position where STR drop to ~150 MB/s. Looking at the read STR graph from overclockers.at show this to be the case around 4.6 TB, or "roughly in the middle" of the platters. It also matches the average read speed of 152 MB/s very well. Apparently Seagate choose to optimize average acess times by placing the landing zone in the middle, while sacrificing 40 MB/s write speed. Sounds like a good general purpose trade-off.

Furthermore: at 6k rpm (according to overclockers.at) a maximum speed of 190 MB/s is quite large and way above what drives with 1 TB platters can achieve. This suggests that without shingling the drive would have 1.1 - 1.2 TB platters. Or where else should this performance come from? Shingling "only" increases the track density by overlapping them, but doesn't change the linear density, does it?

Oddball question, and potential quick-and-dirty way to see if large sequential writes bypass the cache -- what happens when you attempt to write a single file, that is larger than the cache (e.g. a bluray disk image), to the disk? This should force the drive to show its true colours, and give little opportunity to mistake sequential data for random. I would also expect that backing up large numbers of largish disk images would be a valid use-scenario for a very large archive disk (meaning that if it gets indigestion doing this, it's got some problems for its core business).

I agree - identifying such a case as sequential access, spanning many shingled blocks, should be trivial.

@Kevin: do you know what happens during that raid rebuild? Is the content of the valid drive simply copied to the new one, or are the contents of both compared and only differences are resolved? Does the raid rebuild time of the Archive recrease if it's freshly formatted (like sending it a TRIM command). And if you say that in a disk in real there will never be any "clean" blocks - does this mean this drive should actually get TRIM commends to help the garbage collection?

MrS

Edited by [ETA]MrSpadge

Share this post


Link to post
Share on other sites

@Kevin: Something MrSpadge said that made me wonder... If, during your RAID1 rebuild test, you had inserted a brand-new drive, instead of having reinserted the one previously used, would the rebuild times be any different?

Having watched the Skylight paper presentation, Aghayev mentioned (at the end, during the Q&A, around the 24:30 mark) that when volatile cache is enabled (which is the default - however, they had disabled the DRAM cache for most of their other tests), data is written directly to the destination at full speed, and bypasses the persistent cache entirely.

So based on that finding, one can infer that sequential writing to blank media would have similar transfer rates to PMR drives. And since their research is specifically on drive-managed SMR, and the only drive-managed SMR drive on the market right now is the Seagate Archive drive, I am assuming that their findings apply to this drive directly.

Is there a chance you could repeat the RAID1 rebuild test with a blank drive? And if you were to inquire from Seagate engineers, perhaps they can shine some more light on this behaviour, and confirm whether any scenarios exist where the persistent cache would be bypassed and data would be written to destination directly?

Thanks in advance :)

Edited by hey_tommy

Share this post


Link to post
Share on other sites

I bought 40 of these units couple weeks ago, having had them on order since December. They were to be put into two 16bay Thunderbolt towers in RAID 6, connected to a Mac Mini 2014, to be at home backing up a client through the internet once per week. Fios 300mb line. Approximate 2TB changes weekly.

Still doing some testing but here is some info for you.

Testing just one box so far.

62 hours to Check/Fix/Rebuild Parity.

AJA tests around 700 for both read and write.

Right now I'm having trouble transferring large files. Unit locks up, whether through Ethernet or another source connected directly by Thunderbolt. Doesn't do the same with HGST drives. Working to discover whether enclosure, Areca card or drives. Locks up doing that same test even if using 6 drives in RAID0.

Testing another enclosure, using Highpoint and mini sas later today.

TM

Share this post


Link to post
Share on other sites

Sounds like the SMR performance profile we noted. That and Highpoint is absolutely not what we'd recommend for the RAID cards.

Share this post


Link to post
Share on other sites

@Kevin: Something MrSpadge said that made me wonder... If, during your RAID1 rebuild test, you had inserted a brand-new drive, instead of having reinserted the one previously used, would the rebuild times be any different?

Having watched the Skylight paper presentation, Aghayev mentioned (at the end, during the Q&A, around the 24:30 mark) that when volatile cache is enabled (which is the default - however, they had disabled the DRAM cache for most of their other tests), data is written directly to the destination at full speed, and bypasses the persistent cache entirely.

So based on that finding, one can infer that sequential writing to blank media would have similar transfer rates to PMR drives. And since their research is specifically on drive-managed SMR, and the only drive-managed SMR drive on the market right now is the Seagate Archive drive, I am assuming that their findings apply to this drive directly.

Is there a chance you could repeat the RAID1 rebuild test with a blank drive? And if you were to inquire from Seagate engineers, perhaps they can shine some more light on this behaviour, and confirm whether any scenarios exist where the persistent cache would be bypassed and data would be written to destination directly?

Thanks in advance :)

Seagate actually didn't provide much feedback on our review... SMR I think is a touchy subject where the underlaying technology is mostly understood but noone wants to fully explain it and risk sharing trade secrets with another company. Also the clean disks from Seagate come pre-tested so it would be hard to find a 100% clean drive. I'm not sure it accepts TRIM commands yet which would work well to get it back to a clean slate.

Share this post


Link to post
Share on other sites

Kevin -

The highpoint cards we use are old ones just for clone RAIDs of our master units. I wanted to rule out the issue was the drives or Areca/enclosure. I only tested 6 drives with highpoint and was able to copy files. So something off with the Areca system or Thunderbolt bridge in compatibility with these Seagates.

In any case, after talking with 4 Seagate technicians since December I'm convinced they have no idea what this drive is for. They all said,before I bought these drives and before your review, for my purpose it should be ok. That I can RAID them. Just performance would suffer, which I didn't care about since backup was over the internet. But after reading your review and the fact these are a brand new class of drives, using SMR technology, I don't want to be a tester for them. Find out in a year or so that data is corrupted, slows down to a crawl or some other catastrophe. I'm going back to HGST 6TB drives for now. Let the future sort itself out with me being the guinea pig.

Edited by tzmljm

Share this post


Link to post
Share on other sites

The use cases certainly haven't been defined well in this case. That's why HGST is going host managed. That way they don't have to worry about supporting more than about five customers.

Share this post


Link to post
Share on other sites

Host managed also has the benefit of allowing quick software updates or fixes. Updating drive firmware is probably more painful.

(but on ther other hand there's a lot which oucld go wrong during software updates..)

MrS

Edited by [ETA]MrSpadge

Share this post


Link to post
Share on other sites

StorageReview -

Did Seagate specifically tell you these drives were not for use in a RAID configuration? I was told the opposite from 4 techs.

Share this post


Link to post
Share on other sites

Product manager and engineer level... quite a few steps up from a tech level.

Share this post


Link to post
Share on other sites

Thanks Kevin for the reply.

Figured it was much higher level. I spoke with 4 techs 4+ hours combined on phone during a 75 day period before purchasing. Multiple times being put on hold while they tried finding someone with knowledge about these drives. Each time being told it was ok for RAID use. Too bad these techs didn't have same access as you do. You would think they should....or at least be passed along the same info. I don't blame the techs...Not their fault. They were always friendly and generally concerned they could not provide more info. Tried as best as they can but had limited resources.

Wish I read your article before purchasing as I would never have done so. Never heard of StorageReview.com until I went searching after having problems. Per your review, SMR is not for RAID use as it stands today.

But as single archive drive they should be fine. As long as people follow safe practices, like with any drive, by having a backup copy for very important data.

Share this post


Link to post
Share on other sites
Per your review, SMR is not for RAID use as it stands today.

The "today" is very important in this sentence. From what I've read this should be fixable via software, i.e. either the drive firmware needs tweaks, the RAID controller driver / NAS software or both. On the other hand - I'm sure the Seagate engineers have already put quite some thought into this matter..

MrS

Share this post


Link to post
Share on other sites

Its largely dependent on the SMR design. In the next year we are going to see some newer designs that will much better cope with RAID or sustained writes. Only so much can be fixed with firmware. Remember drives are doing much more than what they originally had to cope with, so if its not built from the ground up that will cause some of these problems if you move outside the scope of limited workload. Moving data around at the same time as you are writing it is possible to do fast, but not without more DRAM, faster controllers, etc.

The nice thing amount host managed drives isn't the firmware upgrading aspect. Instead its the fact that since the host knows the limitations, it can be coded to work around the slowdowns? Drive1 bogging down? Ok I'll shift to Drive2 while I shuffle things around then switch back to Drive1.

Share this post


Link to post
Share on other sites

Anyone know what is new with V2? I really need at least 8TB drives. I only have room for 12 drives in my system and no physical space for a second array. The HE drives are out of my budget. I'm hoping V2 fixes the problems with RAID but I'm not betting on it.

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