Seagate 8TB Shingled Drives in UnRAID


Recommended Posts

There's just one thing you shouldn't do with them, and that's two simultaneous writes, e.g. parity rebuild AND write new data, other than that, I love them.  I should add, some of my media files are over 100GB each and no issues.

 

 

Can you explain why this is?  I am considering consolidating two servers into one using these drives, but suspending all writes to the array during the monthly parity check would be a problem, especially given how long an 8x8TB array would probably take to do the check....  Also, what if two users are writing to the array at the same time, and happen to be hitting the same disk? 

 

Thanks.

Link to comment

Simultaneous writes aren't, per se, a problem => but they can increase the likelihood of data being routed through the persisent cache which may otherwise be written directly to a zone.    This will somewhat slow down the writes -- but probably not enough to be an issue as long as you don't do so many of them that the persistent cache gets full.    There's been enough testing of this on various UnRAID systems that it seems this is VERY unlikely.

 

Link to comment

... especially given how long an 8x8TB array would probably take to do the check..

 

You probably already know this, but just in case:  A parity check with an 8TB parity drive will indeed take a long time ... but it won't be appreciably longer with 8 drives than it would be with any other number of drives => it has to go through 8TB no matter what.  However, if the other drives were smaller, it would actually take LONGER, since for each different size drive it will slow down a good bit as it goes through the inner cylinders on the different size drives.    The more different sizes involved, the longer it will take.  But if all the drives are 8TB, it doesn't make much difference whether you have 2 of them, 8 of them, or 20 of them.

 

 

Link to comment

Anyone know what the difference is between the ST8000VN0002 and the ST8000AS000? I know the VN0002 is being marketed as an NAS drive. Just wondering if it's really worth the extra $50.00?

 

The IronWolf (ST8000VN0002) is not SMR (Shingled), thus very different. Is it worth $50 is dependent on workload, etc.

Link to comment

Anyone know what the difference is between the ST8000VN0002 and the ST8000AS000? I know the VN0002 is being marketed as an NAS drive. Just wondering if it's really worth the extra $50.00?

 

The IronWolf (ST8000VN0002) is not SMR (Shingled), thus very different. Is it worth $50 is dependent on workload, etc.

Thanks. Think I'll save the money.

Link to comment

Parity check killed my first drive. The second was fine.

 

Sent from my SM-N920V using Tapatalk

 

Apart from MY 3 dead drives... Parity check killed drives on two separate occasions.. But apart from me, everyone else seems fine...

 

Are you both confirming that following testing of the drive for infant mortality things were fine and then a Parity Check killed the drive? Can you post the evidence to support these claims we can view? I only ask as I assume you would have collected this to support your RMA claim and it is of benefit to the community.

 

As for reliability I have empirical evidence that these drives in good health are indeed an excellent choice for use with unRAID.

 

I have these running in my Backup Server -  an all Seagate Shingled  8TB drive array (single Parity). Running alongside my Main Server - an all WD Red 3TB drive array + 1 x 8TB data and 1 8TB Data (Single Parity).

 

This setup has been running PERFECT 24x7 now for ~:

 

1y, 3m, 24d, 8h

 

In addition to the evidence I collected at the beginning of this journey (please read initial posts) here is some in life data:

 

Parity History for Backup Server:

 

2016-10-01, 19:04:53	19 hr, 4 min, 52 sec	116.5 MB/s	OK
2016-09-21, 01:07:39	23 hr, 14 min, 18 sec	95.6 MB/s	OK
Aug, 01, 16:25:46	16 hr, 25 min, 42 sec	135.3 MB/s	OK
Jul, 01, 15:51:40	15 hr, 51 min, 37 sec	140.1 MB/s	OK
Jun, 01, 17:47:45	17 hr, 47 min, 41 sec	124.9 MB/s	OK
May, 01, 18:53:44	18 hr, 53 min, 40 sec	117.6 MB/s	OK
Apr, 05, 12:47:54	16 hr, 15 min, 19 sec	136.7 MB/s	OK
Apr, 03, 08:02:32	16 hr, 39 min, 57 sec	133.4 MB/s	OK
Mar, 01, 15:55:59	15 hr, 55 min, 55 sec	139.5 MB/s	OK
Feb, 10, 01:36:07	1 day, 3 hr, 57 min, 1 sec

 

Parity History for Main Server:

 

2016-10-01, 20:18:02	19 hr, 48 min, 1 sec	112.3 MB/s
Aug, 01, 18:47:49	18 hr, 17 min, 47 sec	121.5 MB/s
Jun, 01, 19:29:00	18 hr, 58 min, 56 sec	117.1 MB/s
May, 01, 23:10:57	22 hr, 40 min, 52 sec	98.0 MB/s
Apr, 05, 15:26:53	18 hr, 54 min, 20 sec	117.6 MB/s
Apr, 01, 19:39:23	19 hr, 9 min, 19 sec	116.0 MB/s
Mar, 01, 19:57:13	19 hr, 27 min, 9 sec	114.3 MB/s
Feb, 01, 18:44:41	18 hr, 14 min, 36 sec

 

There are a few spikes due to load. I run my daily backups at 3am (3 hours after a Parity Check has begun) and I don't stop the backups when this Check is running. My backup is going from Main -> Backup Server via  a SyncBack managed compare, copy then verify.

 

I have had 2 instances of a need for rebuilding a drive over the year in this setup:

 

3TB drive on Main Server: 9 hr, 24 min, 40 sec

8TB drive on Backup Server: 15 hr, 59 min, 10 sec

 

Nothing wrong here.

Link to comment

I have had two infant mortalities during preclears. Once in the array, no problems as long as you understand the speed bumps on large writes. I just set Mover to run late late at night when no one is around.

 

In what scanario have you experienced the speed bumps?

 

Size of file(s), Array configuration etc?

 

I ask only because, no matter what I do I cannot replicate it.

 

 

Link to comment

I have had my 8tbs for over a year and never had problems. I too have write speed issues on large files (20gb+) but nothing to worry about.

 

 

Sent from my iPhone using Tapatalk

 

Really?? What do you mean "write issue"? I just tried again on my Backup Server. Files in 10GB increments from 10GB up to 200GB via MC on the console. Disk to disk copy. No material speed variance what so ever!?

 

Same as I asked Interwebtech, can you describe exactly what you do to get this "issue". Like I mentioned above I cannot replicate it. No matter what size file I use (as my previous results have indicated), there seems to be no performance impact at all.

 

I really want to replicate this. There is nothing special about my setup at all.

Link to comment

It's been a while since I was using those drives. Might not have even been under unRAID but FlexRAID... but I know the 1st Parity check killed them. The other drives were pretty full so no doubt the parity run was a heavy run with continual writing.

 

Have you done a test with yours that involves writing say 200GB in one chunk to the array, not to a cache drive?  I may have just had 1st batch problems as they were early drives!

Link to comment

It's been a while since I was using those drives. Might not have even been under unRAID but FlexRAID... but I know the 1st Parity check killed them. The other drives were pretty full so no doubt the parity run was a heavy run with continual writing.

 

Have you done a test with yours that involves writing say 200GB in one chunk to the array, not to a cache drive?  I may have just had 1st batch problems as they were early drives!

 

Yes, thats what my test above was. No Cache. Disk to Disk. No slow down irrespective of file size above 10GB onwards ....

Link to comment
  • 3 weeks later...
  • 2 weeks later...

You'd have to be nuts to use a shingled drive in an array like this. Figure 20GB of the drive is dedicated write cache. Every time sustained writes fill that up, the drive locks in a busy cycle until it flushes the cache in a slow stream of read-modify-write cycles to the shingled storage area.

 

Or you could wait for someone to invent a desktop file system and operating system that can handle this at the host level. Probably won't happen any time in the next decade for consumer or prosumer accessible software.

 

Just because you can do it, doesn't mean that you necessarily should.

Link to comment

You'd have to be nuts to use a shingled drive in an array like this. Figure 20GB of the drive is dedicated write cache. Every time sustained writes fill that up, the drive locks in a busy cycle until it flushes the cache in a slow stream of read-modify-write cycles to the shingled storage area.

 

Or you could wait for someone to invent a desktop file system and operating system that can handle this at the host level. Probably won't happen any time in the next decade for consumer or prosumer accessible software.

 

Just because you can do it, doesn't mean that you necessarily should.

Is your point that it would be unacceptably slow?  The purpose of this thread is to document how this setup performs in actual practice. I have two in my unRAID and have no performance difference vs. the NAS drives I have been running for years.

 

If there were actual performance issues I would expect to read about them right here.

 

 

Sent from my SM-N920V using Tapatalk

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.