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?

Link to comment

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.

 

Link to comment
  • 1 year later...
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.

Link to comment

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
Link to comment

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 2
Link to comment
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..

Link to comment
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

Link to comment
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. 

Link to comment

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

 

 

 

 

Link to comment
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.

Link to comment
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. 

Link to comment
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.

Link to comment

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.

 

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.