johnsanc Posted November 12, 2016 Share Posted November 12, 2016 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? Quote Link to comment
interwebtech Posted November 12, 2016 Share Posted November 12, 2016 I went with a pair of these: Seagate NAS HDD ST8000VN0002 pdf: http://www.seagate.com/www-content/product-content/nas-fam/nas-hdd/_shared/docs/nas-hdd-8tb-ds1789-5-1510DS1789-5-1510US-en_US.pdf Quote Link to comment
johnsanc Posted November 12, 2016 Author Share Posted November 12, 2016 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. Quote Link to comment
HellDiverUK Posted November 13, 2016 Share Posted November 13, 2016 Another vote for the ST8000VN0002. Quote Link to comment
Forusim Posted November 13, 2016 Share Posted November 13, 2016 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. Quote Link to comment
HellDiverUK Posted November 13, 2016 Share Posted November 13, 2016 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. Quote Link to comment
johnsanc Posted November 13, 2016 Author Share Posted November 13, 2016 Is there a reason to go for ST8000VN0002 over the ST8000VN0022? Quote Link to comment
HellDiverUK Posted November 13, 2016 Share Posted November 13, 2016 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. Quote Link to comment
garycase Posted November 15, 2016 Share Posted November 15, 2016 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. Quote Link to comment
ashman70 Posted November 15, 2016 Share Posted November 15, 2016 I have two Seagate archive 8TB drives as parity drives in my monster server, zero issues. Quote Link to comment
garycase Posted November 16, 2016 Share Posted November 16, 2016 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. Quote Link to comment
pras1011 Posted November 26, 2017 Share Posted November 26, 2017 (edited) 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 November 26, 2017 by pras1011 Quote Link to comment
DZMM Posted November 26, 2017 Share Posted November 26, 2017 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. Quote Link to comment
garycase Posted November 26, 2017 Share Posted November 26, 2017 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. 1 Quote Link to comment
SSD Posted November 26, 2017 Share Posted November 26, 2017 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. 2 Quote Link to comment
uldise Posted November 26, 2017 Share Posted November 26, 2017 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.. Quote Link to comment
DZMM Posted November 26, 2017 Share Posted November 26, 2017 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 Quote Link to comment
BRiT Posted November 26, 2017 Share Posted November 26, 2017 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. Quote Link to comment
HellDiverUK Posted November 26, 2017 Share Posted November 26, 2017 The Archive drives have a 25GB non-shingled cache area. It all goes to crap when you fill that cache. 1 Quote Link to comment
BRiT Posted November 26, 2017 Share Posted November 26, 2017 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. Quote Link to comment
JorgeB Posted November 26, 2017 Share Posted November 26, 2017 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: Quote Link to comment
garycase Posted November 27, 2017 Share Posted November 27, 2017 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. Quote Link to comment
DZMM Posted November 27, 2017 Share Posted November 27, 2017 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. Quote Link to comment
SSD Posted November 27, 2017 Share Posted November 27, 2017 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. Quote Link to comment
garycase Posted November 27, 2017 Share Posted November 27, 2017 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. Quote Link to comment
Recommended Posts
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.