johnsanc

Best 8TB Parity Drive?

Recommended Posts

I currently primarily use 8TB Seagate Archive drives, and I even use one for parity. I've had no real issues, but I don't think its really optimal. Now that there are more options for 8TB drives I was thinking of moving the Archive drive from parity to data and replacing it with a drive better suited for parity.

 

So what are the best options for a parity drive considering most of my data drives are 8TB Seagate Archives?

Share this post


Link to post
Share on other sites

I was looking into those IronWolf drives a bit earlier today. Seems pretty good for the price. Was also considering WD Red, but I thought the 7200 rpm and 256mb cache would be a better fit for parity.

Share this post


Link to post
Share on other sites

Also using Seagate Archive 8 TB for data.

For parity I took WD Red 8 TB (Helium) from disassembled My Book (240€).

Runs at 170 MB/s and 30° C. Pretty silent also.

 

Share this post


Link to post
Share on other sites

Yes, the WD80EZZX shucked from MyBook units is a good option too, I have a few of those and have had no problems, apart from the wear levelling causing constant seeks, which is a little annoying from a noise perspective.

Share this post


Link to post
Share on other sites

Is there a reason to go for ST8000VN0002 over the ST8000VN0022?

 

Same drive except the 0002 is labelled "NAS" and the 0022 is labelled "Ironwolf".  Same drive, different label.

Share this post


Link to post
Share on other sites

Either the Seagate Ironwolf or the WD Reds are good choices for your parity drives.

 

I prefer the WD Reds for two reasons:  (a) the sealed helium construction; and (b) lower rpm = less heat and a bit less power consumption while still providing PLENTY of performance.

 

Share this post


Link to post
Share on other sites

I agree that the archive drives have shown VERY good performance in many UnRAID arrays => I've used several of them myself for applications (not UnRAID) where the write patterns aren't extensive random operations.  Seagate has indeed done a VERY good job of mitigating the potential issues of the shingled technology (I wrote a very detailed explanation of this in another thread).

 

Notwithstanding that, some would prefer to have non-shingled parity drives -- and in situations where you typically have multiple users writing to UnRAID at the same time, that's probably a good idea, as the write patterns would be much more random than with a single active user, which may stress the persistent cache structure.    Not a high likelihood of that, but using a non-shingled parity drive completely eliminates any possibility of it.

 

Share this post


Link to post
Share on other sites

I have the Seagate Archive 8TB for the parity and I am thinking of changing it for a faster drive.

 

Has anyone done this and was it faster?

Edited by pras1011

Share this post


Link to post
Share on other sites
23 minutes ago, pras1011 said:

I have the Seagate Archive 8TB for the parity and I am thinking of changing it for a faster drive.

 

Has anyone done this and was it faster?

I came from a 6TB Toshiba X300 to a seagate archive and mostly I don't spot the speed difference, although it is a bit slower. 

 

But, when it's bad it's really bad - talking KB/s rather than MB/s if I'm moving a lot of files.  I can live with it for now as I've 'adjusted', but my next update in a few months at current write rate will be to something else e.g. a diff seagate or a Toshiba N300 (familiar with tosh drives - see sig) so I don't get the painful slowdowns, and I'll move the archive drive to the array.

Share this post


Link to post
Share on other sites

As you likely know, the "really bad" slowdowns aren't because the drive has performance issues -- it's because the multiple random writes you're doing have hit the "wall" where the persistent cache on the shingled drive is full, and it has to come to a screeching halt while it moves data out of the cache.     ANY non-shingled drive will eliminate this issue.

  • Like 1

Share this post


Link to post
Share on other sites

Faster for what?

 

Parity is only involved in write operations and parity checks.

 

For writes, the optimal parity you want high RPM, which today means 7200 RPM. The WD REDS have the slowest RPM of any drives - slower than the archives. So if speed is the issue, a move to the reds would be a step backwards. The HGST NAS, WD Red Pro, and Seagate Ironwolf drives are all 7200 RPM.

 

But parity and data are working together on writes, and the gate is typically the slower one. So unless you have 7200 RPM data, a 7200 RPM parity is not that beneficial. A similar story for parity checks, which are gated by the slowest disk at that point in the check.

 

Faster parity does help more with parallel writes. But these are still very slow and should be avoided when possible.

 

The fastest parity would be SSD, but given that is not practical, the next fastest is RAID0. My parity is a RAID0 pair of 2 4T 7200 RPM drives. Which means my parity is virtually never the bottleneck in single writes, and helps the most is parallel writes. That's as good as it gets.

 

Turning on turbo write is the best way to speed up writes, with the downside of having all disk spinning.

 

But practically speaking, updating parity to get more speed is not going to be life altering, but you may get a modest little bump. @Lev recently went the RAID0 route and was pretty happy.

 

I really like my RAID0 setup. Besides the modest did bump, it allows me to repurpose two older smaller disks for parity and buy a single new large disk for data and immediately have access to its full capacity. Most have to buy 2 of the new larger disks before seeing any advantage of the larger disk.

 

RAID0 parity requires a hardware RAID card. The only ones I know work with unRaid are the ARECA brand.

  • Like 1

Share this post


Link to post
Share on other sites
24 minutes ago, SSD said:

RAID0 parity requires a hardware RAID card. The only ones I know work with unRaid are the ARECA brand.

i had RAID0 parity on Dell PERC H710p, and RAID1 for cache on the same controller for the same time. it just works very well. After MB upgrade, now i have RAID1 for cache from MB built-in Broadcom 2208 - it both uses Megaraid driver..

Share this post


Link to post
Share on other sites
1 hour ago, garycase said:

As you likely know, the "really bad" slowdowns aren't because the drive has performance issues -- it's because the multiple random writes you're doing have hit the "wall" where the persistent cache on the shingled drive is full, and it has to come to a screeching halt while it moves data out of the cache.     ANY non-shingled drive will eliminate this issue.

It's a performance issue when the drive slows down to KB/s!!! 

 

It doesn't just happen on my system when there are small writes (had a lot of help from LT trying to fix) - it happens when I'm moving large files e.g. movies around.  I 'accept' it for now, but I will definitely be replacing my parity drive when I add my next drive

Share this post


Link to post
Share on other sites
46 minutes ago, DZMM said:

It's a performance issue when the drive slows down to KB/s!!! 

 

It doesn't just happen on my system when there are small writes (had a lot of help from LT trying to fix) - it happens when I'm moving large files e.g. movies around.  I 'accept' it for now, but I will definitely be replacing my parity drive when I add my next drive

 

I have never had that happen -- even when I migrated from 5 4TB data drives to 2 8TB drives and then migrated to 3 8TB drives, all done using the unbalance plugin. At no point in time was the data writes ever below 50 MB/s. 

Share this post


Link to post
Share on other sites
1 hour ago, HellDiverUK said:

The Archive drives have a 25GB non-shingled cache area.  It all goes to crap when you fill that cache.

 

Yes, but when I migrated 13 TBs onto 2 8TB Drives and then rebalanced 13 TBs onto 3 8TB drives I never ever hit that 25 GB wall.

Share this post


Link to post
Share on other sites

It's been proven multiple times that the Archive drives work very well for large file sequential transfers, you may hit the "wall" if your work with lots of small files, I've posted this before but here's an example of a large transfer to a server with Archive drives only, speed never slows down for the ~150GB transfer:

 

5a1b3deda3e2b_Screenshot2017-07-2313_50_52.png.1a571b90428e8cf45c30983a49551dd0.png

 

 

 

 

Share this post


Link to post
Share on other sites
7 hours ago, DZMM said:

It's a performance issue when the drive slows down to KB/s!!! 

 

It doesn't just happen on my system when there are small writes (had a lot of help from LT trying to fix) - it happens when I'm moving large files e.g. movies around.  I 'accept' it for now, but I will definitely be replacing my parity drive when I add my next drive

 

As Johnnie noted, writing large files isn't an issue.    The drive recognizes that a full shingled block is involved in the write, so it simply writes directly to the shingled area and the cache is never even involved.    The cache is used when a write doesn't fill a full block and there will have to be reads/rewrites of the shingled area to actually write the data.   If you're writing a LOT of random data, the cache can in fact fill up ... and that's when the performance comes to a screeching halt.

 

You said it happens when you're "moving large files around" => Note that this results in both writes to the destination location and deletes from the source location.   If you're doing several of these at once, this can cause small segments of each movie to be written, which "look" like small random writes, and thus the cache gets involved.  It will also cause other writes on the parity drive as parity is updated for the file deletions -- and these are in fact small writes, since it's just directory info being updated.   I suspect that's how you're managing to "hit the wall" of performance due to the cache being filled.

Share this post


Link to post
Share on other sites
10 hours ago, garycase said:

 

 

You said it happens when you're "moving large files around" => Note that this results in both writes to the destination location and deletes from the source location.   If you're doing several of these at once, this can cause small segments of each movie to be written, which "look" like small random writes, and thus the cache gets involved.  It will also cause other writes on the parity drive as parity is updated for the file deletions -- and these are in fact small writes, since it's just directory info being updated.   I suspect that's how you're managing to "hit the wall" of performance due to the cache being filled.

Yep, that's exactly my issue and why I will move it to the array at the next upgrade as having to in my setup worry about the type of writes on my server isn't acceptable behaviour for me.

 

In an environment where you only write to the array and are not moving files between disks, then these drives would be perfect. 

Share this post


Link to post
Share on other sites
6 hours ago, DZMM said:

Yep, that's exactly my issue and why I will move it to the array at the next upgrade as having to in my setup worry about the type of writes on my server isn't acceptable behaviour for me.

 

In an environment where you only write to the array and are not moving files between disks, then these drives would be perfect. 

 

Just have to mention that you are the exception and not the rule on this. However Seagate has integrated the PMR cache, it works quite well. Never seen any complaints. I had an earlier generation 5T SMR, that I didn't even realize was SMR, and had all the symptoms of hitting the wall, but with the 8T, never had a problem, even moving files around.

Share this post


Link to post
Share on other sites

Note also that even if you move the drive to the array, it's still possible to fill the cache if you're doing a log of "moving around" that impacts the same disk.    MUCH less likely you'd see a problem than with a parity drive, but still possible.    However, as SSD noted above, it's very rare to see this issue with typical UnRAID usage (even as a parity drive).    I think you'll be just fine if you use a non-shingled drive as parity and relegate your shingled units to data drives.

 

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


Copyright © 2005-2017 Lime Technology, Inc. unRAID® is a registered trademark of Lime Technology, Inc.