Which drive for parity?


Recommended Posts

I am in the process of building my first unRAID server. Here is the list of hard drives i have available. I am planning to use the two SSD drives as the cache but i am confused on what to use as the parity. What do you guys recommend?

 

1) Seagate 3TB Desktop HDD SATA 6Gb/s 64MB Cache 3.5-Inch Internal Bare Drive (ST3000DM001)
2) Seagate 3TB Desktop HDD SATA 6Gb/s 64MB Cache 3.5-Inch Internal Bare Drive (ST3000DM001)
3) WD Red 3TB NAS Hard Disk Drive - 5400 RPM Class SATA 6 Gb/s 64MB Cache 3.5 Inch - WD30EFRX
4) WD Red 6TB NAS Hard Disk Drive - 5400 RPM Class SATA 6 Gb/s 64MB Cache 3.5 Inch - WD60EFRX
5) WD Red Pro 6TB 3.5-Inch SATA III 7200rpm 128MB Cache NAS Internal Hard Drive (WD6002FFWX)
6) Samsung 850 EVO 500GB 2.5-Inch SATA III Internal SSD
7) Samsung 850 EVO 500GB 2.5-Inch SATA III Internal SSD

 

 

Link to comment

Yes - 7200 RPM is better as parity than 5400.

 

If parity is 5400RPM, you are gating the write speed of every disk. So whether the data disk is 7200 or 5400, write speed is the same.

 

If parity is 7200RPM, and you are writing to a disk that is spinning at 7200RPM, you will get faster writes.

 

(This is for "normal" unraid writes, not "turbo write")

Link to comment

I would say use your best drive/drives as parity because they are the heaviest used drives. I'd go with the 6TB Red Pro for the extra endurance and 7200rpm. 

 

For example, I just put in (10) WD Red 8TB as data and (2) Seagate Ironwolf Pro 8TB for parity. Even though the Seagate Ironwolf Pro/WD Red Pro drives are much more since you are only buying one or two for parity it's worth it to me. For data drives the extra cost just isn't worth it.

 

Edit: Also avoid the SEAGATE 3TB DRIVES AT ALL COSTS. Those were some of the worst drives for reliability with double digit failure rates. I'm pretty sure they've fixed them now but either way just go with the newer Seagate or WD series drives and you'll be fine.

Edited by TBSCamCity
Link to comment
8 hours ago, TBSCamCity said:

I would say use your best drive/drives as parity because they are the heaviest used drives.

Depends on your use case. If most of your activity is reading, the parity drive is never used. Parity only participates in writes, or in case of a drive failure.

Link to comment
19 minutes ago, jonathanm said:

Depends on your use case. If most of your activity is reading, the parity drive is never used. Parity only participates in writes, or in case of a drive failure.

 

You can also argue that the parity drive is the LEAST important drive in the array. It is only called upon in cases of a drive failure or drive upgrade. My array has depended on parity only a very few times in my array's 10 years. Not diminishing its importance, but my stress level when a parity disk fails is much lower than if a data disk fails. Because a data disk contains the actual data, and is on the front lines, so to speak.

 

I use a hardware RAID0 parity in my array, made of 2 4T 7200 RPM HGSTs. It is quite fast. Since these HGSTs are among if not THE most reliable disks around, I consider my risk very low. But if either of them failed, my parity would be lost.

Link to comment
2 hours ago, bjp999 said:

It is only called upon in cases of a drive failure or drive upgrade

@bjp999, you got me thinking, with your RAID0 parity arrangement. We have turbo write, why not turbo read? We have 2 copies of every file, kinda like a crippled RAID10 if you count the parity generated version. So, why not issue an interleaved read command, with the first sector of a file requested from the physical drive, the second sector requested from the parity reconstructed version? As each request is filled, the next queued sector is assigned to whichever thread checked in with valid results.

Theoretically, you could almost double throughput, depending on where your bottlenecks are.

 

I realize it would be a HUGE amount of work for Tom, but the upside could be a significant increase in read speed.

Link to comment
8 hours ago, jonathanm said:

Depends on your use case. If most of your activity is reading, the parity drive is never used. Parity only participates in writes, or in case of a drive failure.

Yes I forget about that sometimes. I do a lot of writing all the time so it's very important for me.

Link to comment
6 hours ago, jonathanm said:

@bjp999, you got me thinking, with your RAID0 parity arrangement. We have turbo write, why not turbo read? We have 2 copies of every file, kinda like a crippled RAID10 if you count the parity generated version. So, why not issue an interleaved read command, with the first sector of a file requested from the physical drive, the second sector requested from the parity reconstructed version? As each request is filled, the next queued sector is assigned to whichever thread checked in with valid results.

Theoretically, you could almost double throughput, depending on where your bottlenecks are.

 

I realize it would be a HUGE amount of work for Tom, but the upside could be a significant increase in read speed.

 

Interesting idea, and could be useful when max read I/O is needed. But reads are pretty darn fast anyway, fast enough to saturate the LAN. And if there is any processing (e.g., transcoding) required the processing time is going to become the bottleneck pretty quickly. So the use cases when the ultimately fast read would come into play might be limited.

 

I tend to not be a big fan of the "turbo" / reconstruct write. It has it's place on big write operations (e.g., initial load of an array), but I'd often rather have multiple things occurring independently on different disks on the array, rather than trying to make one very fast at the expense of other operations that are trying to complete in parallel. For example, if I am watching a high bandwidth movie, I really don't want turbo write to cause ANY stuttering on the disk that I am watching that is totally independent of the disk to which the write is affecting. I really could care less if a background write is happening at 50MB/sec, 80MB/sec or even 120MB/sec. I am watching a movie and just want a very stable read performance!!!


unRAID native writes works best for me 97% of the time!

 

And I think I'd feel the same about turbo read. Here is a real work example where it would slow me down dramatically. I have a process of updating md5s periodically. I run each disk in a separate process (up to about 8 at a time works fine). If I were using this turbo read function, it would thrash itself to death!!

 

Link to comment

Considering disk drives never read a single sector, and unRAID places the contents of a single file on a single disk, it is going to very hard to beat read performance with any kind of reconstructed read. Typically the "next" read is already in cache on the disk drive, limited by track size and file fragmentation.

 

This not like RAID 10 at all. Split or dual reads on duplicated data is one disk operation verse one disk operation. Reconstructed read is one disk operations verse the slowest of N disk operations. Every disk operation in the reconstructed read has to finish faster than the single direct read. Like the famous bear race, the single direct read only has to finish second to last to win.

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.