limefrog Posted October 28, 2015 Posted October 28, 2015 Hey folks, I've done a lot of homework with the pros/cons of 5400 rpm vs 7200 rpm drives, but still need some input from you. Goals: -low power, low noise Plex server in a Norco 4224 (that I will outfit with quiet aftermarket 120mm fans) Seagate 6TB Desktop -higher power (7200 rpm) -more reliable than WD Red by most recent Backblaze report (https://www.backblaze.com/blog/hard-drive-reliability-stats-for-q2-2015/) (https://www.backblaze.com/blog/our-6tb-hard-drive-face-off-revisited/) -cheapest (~$230) WD Red 6TB -low power (5400 rpm) -more expensive than the higher RPM Seagate (~$250) HGST 6TB Deskstar -higher power (7200 rpm) -most expensive ($270) -2 and 4TB versions have the best track records with Backblaze (no data on their 6TB versions) It bewilders me that the lower RPM WD Red is more expensive than the Seagate, which got higher marks for reliability by Backblaze. Q1) Obviously the 7200 rpm drives will be louder because a) they spin faster and b) they run hotter and thus require more fan cooling. But since my primary use will be for Plex (and a max of 3 users transcoding at a given time), won't I only have at maximum 3 drives spinning at a given time? The noise level, increased temp and increased power requirements of 7200 rpm drives seem trivial if only 3 of the 24 drives are spinning at any given time (not including the monthly parity check when all 24 drives would be spinning).
ashman70 Posted October 28, 2015 Posted October 28, 2015 You are comparing NAS drives to desktop drives, not exactly a fair comparison, you also neglect to mention warranty, the Seagate has a 2yr warranty and the WD Red has a 3yr warranty as does the HGST drive. If you want low power, then I would suggest either WD Green drives or the WD Red drives you have already looked at. You have to keep in mind that the Back blaze reports are for drives used in their storage pods in their environment, what kind of cooling do they have in their pods, the rooms in which the pods reside, what temps do their drives run at, what you don't know is whether or not their drives were part of a particular batch, how they were handled in shipping and installation etc. You have to take their reports with a grain of salt.
limefrog Posted October 28, 2015 Author Posted October 28, 2015 You are comparing NAS drives to desktop drives, not exactly a fair comparison, you also neglect to mention warranty, the Seagate has a 2yr warranty and the WD Red has a 3yr warranty as does the HGST drive. Great point, this isn't something I considered. You have to keep in mind that the Back blaze reports are for drives used in their storage pods in their environment, what kind of cooling do they have in their pods, the rooms in which the pods reside, what temps do their drives run at, what you don't know is whether or not their drives were part of a particular batch, how they were handled in shipping and installation etc. You have to take their reports with a grain of salt. Got it, another great point, thanks. Any comments regarding my question/rationale for 5400 vs 7200 drives when only 3/24 drives will be spinning? I'm not even sure if my rationale is correct.
c3 Posted October 28, 2015 Posted October 28, 2015 You want low power, low noise, get the low power, low noise drives (not 7200rpm). You can justify 7200rpm many ways, but they will always be more power and more noise than the drives built for low power and low noise. Unless you are watching monthly parity runs, I doubt you'll notice a performance difference.
limefrog Posted October 28, 2015 Author Posted October 28, 2015 You want low power, low noise, get the low power, low noise drives (not 7200rpm). You can justify 7200rpm many ways, but they will always be more power and more noise than the drives built for low power and low noise. Unless you are watching monthly parity runs, I doubt you'll notice a performance difference. Thanks for the input. I guess what I'm really trying to ask is my thinking correct when I say that in a server mainly used for Plex with a max of 3 users at a given time, that I will only have at max 3 drives spinning? The answer to this question isn't obvious to me, and if the answer is yes it seems like the rationale to get a server full of 5400rpm drives to save on power and noise is moot (since only 3 of 24 drives are spinning). Hope that makes sense and thanks for the input.
c3 Posted October 28, 2015 Posted October 28, 2015 Yes, if the drives are configured to spin down and there is only three streams, likely only three drives will be spinning. Any updates might get the parity spinning (access time, etc). I don't think the point is moot. Three 7200rpm drives are more power and noise than three low power, low noise drives.
ashman70 Posted October 28, 2015 Posted October 28, 2015 It depends on the content being accessed through Plex and on what drives that content resides. If you have three drives in your array, its entirely possible all three drives could be spinning to support the plex streams. At the end of the day, I don't think its going to make too much of a difference on your server if you set the drives to spin down every so often, but, yes, the 5400 RPM drives will produce less heat and draw less power in your setup.
interwebtech Posted October 29, 2015 Posted October 29, 2015 Depends on what you are building to support... read and/or writes to the array. Reading from the array, you won't see any difference between the drives. Go green/red and enjoy the power savings. Writes to the array will be at the speed of the slowest drive involved. My personal experience when writing a single MKV @8GB is that it takes longer for the drive to wake up than it takes to send the file over the network Okay maybe a slight exaggeration. In my quest to speed up writes to the array, I made my parity volume from a RAID0 array of 2x 7200 HGST 4TB drives. I am quite pleased with the result even when writing to slower drives.
garycase Posted October 29, 2015 Posted October 29, 2015 Your question seems focused on the read performance => for that, there's virtually NO reason to use 7200rpm drives. The sustained transfer rate of a 1.2TB/platter drive like the WD Red is FAR above what your network can support, so there's NO difference in how fast it can "feed" data to your network; the slightly longer access time is still far faster than the UnRAID buffers will empty (so this won't cause any issues with streaming); and even if you had 3 streams coming from the same disk it's plenty fast enough to support all 3 with no issue. So a faster drive will have absolutely zero benefit. As already noted, there ARE two instances where 7200rpm drives will provide noticeable differences: (1) parity check times (but ONLY if all of the drives are 7200rpm, as the speed can't be any faster than the slowest drive); and (2) as your parity drive IF you're writing to multiple drives at once, where the faster seek time and lower rotational latency will provide a nice improvement in write times, as long as all of the writes aren't to the same drive (in which case it would limit the speeds).
limefrog Posted October 29, 2015 Author Posted October 29, 2015 Thank you to everyone for the input. These are great responses. Yes, if the drives are configured to spin down and there is only three streams, likely only three drives will be spinning. Any updates might get the parity spinning (access time, etc). Got it! This is what I thought so thanks for confirming. I don't think the point is moot. Three 7200rpm drives are more power and noise than three low power, low noise drives. Perhaps moot isn't the right word but at least less significant when compared to having 24/24 drives spinning. The amp difference between 24 spinning drives of 5400 vs 7200 rpm is about 24 amps, but the difference between 3 spinning drives of 5400 vs 7200 rpm is about 3. Reading from the array, you won't see any difference between the drives. Go green/red and enjoy the power savings. Writes to the array will be at the speed of the slowest drive involved. Your question seems focused on the read performance => for that, there's virtually NO reason to use 7200rpm drives. The sustained transfer rate of a 1.2TB/platter drive like the WD Red is FAR above what your network can support, so there's NO difference in how fast it can "feed" data to your network; the slightly longer access time is still far faster than the UnRAID buffers will empty (so this won't cause any issues with streaming); and even if you had 3 streams coming from the same disk it's plenty fast enough to support all 3 with no issue. So a faster drive will have absolutely zero benefit. Good points, I will stick with green 5400 rpm drives. As already noted, there ARE two instances where 7200rpm drives will provide noticeable differences: (1) parity check times (but ONLY if all of the drives are 7200rpm, as the speed can't be any faster than the slowest drive); and (2) as your parity drive IF you're writing to multiple drives at once, where the faster seek time and lower rotational latency will provide a nice improvement in write times, as long as all of the writes aren't to the same drive (in which case it would limit the speeds). I think it's mentioned elsewhere in the forum, that in addition to the benefits of 7200 rpm drives you've listed, higher sustained write speeds when writing directly to an array of 7200rpm drives. This benefit from what I understand can largely be replaced when having a fast cache drive, so that slow inevitable writes to a 5400rpm drive array can be delayed to 3:40am (or whatever time is set).
WeeboTech Posted October 29, 2015 Posted October 29, 2015 There ARE two instances where 7200rpm drives will provide noticeable differences: (1) parity check times (but ONLY if all of the drives are 7200rpm, as the speed can't be any faster than the slowest drive); and (2) as your parity drive IF you're writing to multiple drives at once, where the faster seek time and lower rotational latency will provide a nice improvement in write times, as long as all of the writes aren't to the same drive (in which case it would limit the speeds). Points missed are if you have a large drive with many small files. The time difference to walk a huge drive with many small files can be measurable. In addition, during bulk writes, if turbo write is enabled, A faster parity drive helps since it's in write mode vs read/write. On a small width array with the other data drives in being read in parallel, writes can occur much faster during bulk loads. This may not be as useful with wide arrays, yet on small width arrays, it's useful and very noticeable. A cache negates this, yet in all this time, I've not required a cache since turbo write is so fast.
limefrog Posted October 29, 2015 Author Posted October 29, 2015 In addition, during bulk writes, if turbo write is enabled, A faster parity drive helps since it's in write mode vs read/write. On a small width array with the other data drives in being read in parallel, writes can occur much faster during bulk loads. This may not be as useful with wide arrays, yet on small width arrays, it's useful and very noticeable. Thanks for filling in the info WeeboTech. How does one enable "turbo write" and what is meant by "small width array" and "wide array?"
garycase Posted October 29, 2015 Posted October 29, 2015 The "width" of the array is the number of drives. When turbo write is enabled, writes are done by reading ALL of the drives (except parity and the drive you're writing to); then writing the data drive and parity ... so conceptually there are only 2 disk I/O's [one read, one write ... although each occurs on multiple drives simultaneously]. A normal write requires 4 disk I/O's (but doesn't require that all drives be spinning, like the turbo mode does) ... and even though each pair is done at the same time, there's a full disk rotation required before the 2nd set of operations can occur.
WeeboTech Posted October 29, 2015 Posted October 29, 2015 In addition, during bulk writes, if turbo write is enabled, A faster parity drive helps since it's in write mode vs read/write. On a small width array with the other data drives in being read in parallel, writes can occur much faster during bulk loads. This may not be as useful with wide arrays, yet on small width arrays, it's useful and very noticeable. Thanks for filling in the info WeeboTech. How does one enable "turbo write" and what is meant by "small width array" and "wide array?" small-width 2-6 data drives. wide > 6 data drives. Turbo-write enable/disable. I'm including a cron job for my main unraid file sever that is accessed all day long. in /etc/cron.d/md_write_method I have the following entries. 30 08 * * * [ -e /proc/mdcmd ] && echo 'set md_write_method 1' >> /proc/mdcmd 30 23 * * * [ -e /proc/mdcmd ] && echo 'set md_write_method 0' >> /proc/mdcmd # # * * * * * <command to be executed> # | | | | | # | | | | | # | | | | +---- Day of the Week (range: 1-7, 1 standing for Monday) # | | | +------ Month of the Year (range: 1-12) # | | +-------- Day of the Month (range: 1-31) # | +---------- Hour (range: 0-23) # +------------ Minute (range: 0-59) This turns on turbo-write at 8:30 when I start working, and off at 11:30 when I'm usually done. There is no webGui or other automated function right now. For unRAID 6, the path is /usr/local/sbin/mdcmd ON /usr/local/sbin/mdcmd set md_write_method 1 OFF /usr/local/sbin/mdcmd set md_write_method 0 There is a diminishing return on investment when reading/writing multiple drives and turbo-write. Reads on other drives can interfere with writes to the target drive. However with minimal reads and a large write load, the turbo-write can speed things up with the smaller arrays. I don't have an array larger then 6 drives to test it on, but with the smaller arrays I get good speed.
WeeboTech Posted October 29, 2015 Posted October 29, 2015 The "width" of the array is the number of drives. When turbo write is enabled, writes are done by reading ALL of the drives (except parity and the drive you're writing to); then writing the data drive and parity ... so conceptually there are only 2 disk I/O's [one read, one write ... although each occurs on multiple drives simultaneously]. A normal write requires 4 disk I/O's (but doesn't require that all drives be spinning, like the turbo mode does) ... and even though each pair is done at the same time, there's a full disk rotation required before the 2nd set of operations can occur. I think conceptually it is N(array width)-2 reads + 2 writes(data & parity) With a 4 drive array, it's still 4 IO operations but 2 are reads that are in parallel while 2 are writes that are in parallel and cached. You are not reading and writing to the same drives, thus skip the rotational delay.
c3 Posted October 29, 2015 Posted October 29, 2015 turbo-write trades power for performance. By spinning up and using more drives, the write performance is increased. Each drive can support X many operations per second, rotation speed is one factor in X. The value for X varies, but the number of drives used multiplies this X. As described above, the minimum write requires 4 operations using data from two drives. The time for the write is 4{2reads+2writes}/2X{two drives used}=2/X But you can replace those two reads with reads from all the other drives. The number of reads scales with width, but so does the number of drives involved. For width W, there are 2 writes, and (W-2) reads done on W times X drives. The time for a turbo write is W{1 op per drive}/WxX{W drives used}=1/X
limefrog Posted October 31, 2015 Author Posted October 31, 2015 Thanks for the input guys. Admittedly, some of this went above my head. I'll reread this a few times very slowly ... regardless, I think I get the general gist.
garycase Posted November 1, 2015 Posted November 1, 2015 The "width" of the array is the number of drives. When turbo write is enabled, writes are done by reading ALL of the drives (except parity and the drive you're writing to); then writing the data drive and parity ... so conceptually there are only 2 disk I/O's [one read, one write ... although each occurs on multiple drives simultaneously]. A normal write requires 4 disk I/O's (but doesn't require that all drives be spinning, like the turbo mode does) ... and even though each pair is done at the same time, there's a full disk rotation required before the 2nd set of operations can occur. I think conceptually it is N(array width)-2 reads + 2 writes(data & parity) With a 4 drive array, it's still 4 IO operations but 2 are reads that are in parallel while 2 are writes that are in parallel and cached. You are not reading and writing to the same drives, thus skip the rotational delay. The rotational delay I was referring to is the full rotation that's needed on both the parity drive and the drive being written to in-between the initial reads (which are, of course, done in parallel) and the subsequent writes (which are also done in parallel). With turbo writes there are no rotational delays, since all of the reads (Width -2) and the subsequent writes don't require any full rotations of the drives (only the rotational latency, which is also part of the normal process). In theory the width of the array shouldn't make a lot of difference for turbo writes, but in practice it likely does because of the random nature of rotational latency ... if you're doing a lot of reads it becomes more likely that at least one of them will require a significant part of a full drive rotation. This can, of course, also be true with small arrays, but is more likely to be consistently the case with a lot of drives.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.