Seagate’s first shingled hard drives now shipping: 8TB for just $260

Nope. When a parity check or rebuild starts, all the drives spin up simultaneously.

The auto parity check plug-in was easy to have stagger spinup added.

I have never seen an auto rebuild on unRAID, typically as a manual activity happening shortly after startup while all the drives were still spun up. Could you share that plugin?

If your motherboard doesn't offer staggered spinup, then you won't be able to power up the server.  Mine doesn't.

If your motherboard doesn't offer staggered spinup, then you won't be able to power up the server.  Mine doesn't.

Doh! I should have looked. But you may actually be in luck. The HP Microserver has a solid following in the BIOS mod world. Worth asking about having it unlocked or added.

Many RAID controllers (Areca, Adaptec, LSI, etc.) have staggered spinup options ... but I'm not aware of any motherboards that do.    If you used one of these controllers, and IF UnRAID had staggered spinup support for parity checks and rebuilds, then you could use appreciably smaller power supplies on the larger builds.

I agree would be a very nice feature, as in many (if not most) cases systems are running well below 20% of the PSU's rating (i.e. below the 80+ certification range) solely because they were sized due to spinup power requirements.

Does filesystem matter?

Reiserfs seems to have significant overheard in starting file writes... compared to, say, xfs.

 

On a fragmented reiserfs drive, I've had to wait for more than 30s just for a file copy to start. I'd imagine loads of small file operations are a nightmare.

No, not at all.  Once the drive is spinning, the operational power is very consistent.  Reiser can indeed take a moderately long time to "think" about file placement on relatively full drives (90-95% is typically where this starts to be an issue) -- the actual copy itself runs at full speed, but the initialization can indeed take a good while.    But this doesn't use any more power than a copy with any other file system.  [i suppose the purist view is that "well, it adds 30 seconds to the time before the drive will ultimately spin down" ... so from that perspective it indeed "wastes" power =>  about 2 watts for perhaps 30 seconds ... or 0.000002 kwh  ]

Many RAID controllers (Areca, Adaptec, LSI, etc.) have staggered spinup options ... but I'm not aware of any motherboards that do.    If you used one of these controllers, and IF UnRAID had staggered spinup support for parity checks and rebuilds, then you could use appreciably smaller power supplies on the larger builds.

 

I agree would be a very nice feature, as in many (if not most) cases systems are running well below 20% of the PSU's rating (i.e. below the 80+ certification range) solely because they were sized due to spinup power requirements.

It's not very rare.

x9 support page 4-10 http://www.supermicro.com/manuals/motherboard/C202_C204/MNL-1311.pdf

x10 support http://www.supermicro.com/support/faqs/faq.cfm?faq=19515

Modifying the monthly check for stagger spinup was trivial as I recall (been a few years). Think it was just a cron mod.

Does filesystem matter?

Reiserfs seems to have significant overheard in starting file writes... compared to, say, xfs.

 

On a fragmented reiserfs drive, I've had to wait for more than 30s just for a file copy to start. I'd imagine loads of small file operations are a nightmare.

 

No, not at all.  Once the drive is spinning, the operational power is very consistent.  Reiser can indeed take a moderately long time to "think" about file placement on relatively full drives (90-95% is typically where this starts to be an issue) -- the actual copy itself runs at full speed, but the initialization can indeed take a good while.    But this doesn't use any more power than a copy with any other file system.  [i suppose the purist view is that "well, it adds 30 seconds to the time before the drive will ultimately spin down" ... so from that perspective it indeed "wastes" power =>  about 2 watts for perhaps 30 seconds ... or 0.000002 kwh  ]

Pretty sure he is asking about the filecopy, and yes, filesystem does have an impact on file access time. As mentioned before, the test of 170,000 in one directory is very different that the test of 170,000 file spread across a directory structure X wide and Y deep. Also, the fragmented file (or directory) will impact access.

Many RAID controllers (Areca, Adaptec, LSI, etc.) have staggered spinup options ... but I'm not aware of any motherboards that do.    If you used one of these controllers, and IF UnRAID had staggered spinup support for parity checks and rebuilds, then you could use appreciably smaller power supplies on the larger builds.

 

I agree would be a very nice feature, as in many (if not most) cases systems are running well below 20% of the PSU's rating (i.e. below the 80+ certification range) solely because they were sized due to spinup power requirements.

It's not very rare.

 

x9 support page 4-10 http://www.supermicro.com/manuals/motherboard/C202_C204/MNL-1311.pdf

 

x10 support http://www.supermicro.com/support/faqs/faq.cfm?faq=19515

Ahh => Nice to know.    That, plus using an add-in controller that also support staggered spinup, would let some large builds use very efficient modestly sized power supplies ... but there would still need to be staggered spinup support in UnRAID, so the "Spinup" button, parity checks, and rebuilds didn't overwhelm the power supply.

Does filesystem matter?

Reiserfs seems to have significant overheard in starting file writes... compared to, say, xfs.

 

On a fragmented reiserfs drive, I've had to wait for more than 30s just for a file copy to start. I'd imagine loads of small file operations are a nightmare.

 

No, not at all.  Once the drive is spinning, the operational power is very consistent.  Reiser can indeed take a moderately long time to "think" about file placement on relatively full drives (90-95% is typically where this starts to be an issue) -- the actual copy itself runs at full speed, but the initialization can indeed take a good while.    But this doesn't use any more power than a copy with any other file system.  [i suppose the purist view is that "well, it adds 30 seconds to the time before the drive will ultimately spin down" ... so from that perspective it indeed "wastes" power =>  about 2 watts for perhaps 30 seconds ... or 0.000002 kwh  ]

 

Pretty sure he is asking about the filecopy, and yes, filesystem does have an impact on file access time. As mentioned before, the test of 170,000 in one directory is very different that the test of 170,000 file spread across a directory structure X wide and Y deep. Also, the fragmented file (or directory) will impact access.

Ahh ... since it was buried in the midst of a lot of posts r.e. power consumption I was thinking in those terms.

As for whether it impacts the file write test Daniel is doing, I doubt it, as these drives are very sparsely populated (well under half full).  When you're writing a very large # of very small files they're always MUCH slower than writing large files -- almost certainly due to the directory overhead, which results in a LOT of seek and latency time for each write.  Plus, of course, the typical 4 I/O's per write to maintain parity.

... but certainly as a drive gets very full Reiser's write performance notably slows down => that's not a player her, however, as the drives are neither full nor Reiser.

... As requested, starting the copy of the small files to the Backup Server now and Ill let it run till completion and will check in with progress!

Thanks.  I noticed there was about 2 hours between the first two status posts -- at 0% and 13% ... so extrapolating that rate as long as the drive's don't hit the "full persistent cache" wall I suspect you'll be done with that by about the 15 hour point.    I'll look for your subsequent status updates 

... As requested, starting the copy of the small files to the Backup Server now and Ill let it run till completion and will check in with progress!

 

Thanks.  I noticed there was about 2 hours between the first two status posts -- at 0% and 13% ... so extrapolating that rate as long as the drive's don't hit the "full persistent cache" wall I suspect you'll be done with that by about the 15 hour point.    I'll look for your subsequent status updates 

There seemed to be a website problem in the night that was stopping me from posting. Database connection was the error I got.

Anyway, updated with all the screens shots I took. Up to ~85% now.

... As requested, starting the copy of the small files to the Backup Server now and Ill let it run till completion and will check in with progress!

 

Thanks.  I noticed there was about 2 hours between the first two status posts -- at 0% and 13% ... so extrapolating that rate as long as the drive's don't hit the "full persistent cache" wall I suspect you'll be done with that by about the 15 hour point.    I'll look for your subsequent status updates 

 

There seemed to be a website problem in the night that was stopping me from posting. Database connection was the error I got.

 

Anyway, updated with all the screens shots I took. Up to ~85% now.

Looking fine.  Hard to say whether the drop to the 500kb/s range was due to the drive emptying the persistent cache or just due to the anomalies of a lot of small file copies => but in any event it's pretty clear that these drives are working just fine, even with one used for parity.    The key thing is it didn't "freeze" (as some 3rd party tests have shown the drives can do for a while).    I'm sure your next post will be the final "Done" status for the copies ... not sure if you set it to auto-verify or not; but if you did, just for grins let that run as well -- just to confirm that these will be MUCH faster.

Looking fine.  Hard to say whether the drop to the 500kb/s range was due to the drive emptying the persistent cache or just due to the anomalies of a lot of small file copies => but in any event it's pretty clear that these drives are working just fine, even with one used for parity.    The key thing is it didn't "freeze" (as some 3rd party tests have shown the drives can do for a while).    I'm sure your next post will be the final "Done" status for the copies ... not sure if you set it to auto-verify or not; but if you did, just for grins let that run as well -- just to confirm that these will be MUCH faster.

That increase in speed around 85% was a bit of a spike just as I took the screenshot. I monitored and it went back down to ~500KB/s straight away. I've just added another screenshot at ~89% to the post above to prove it. Next update in that post will be the last one!

And Yes I set it auto verify! Ill let it run.

Looking fine.  Hard to say whether the drop to the 500kb/s range was due to the drive emptying the persistent cache or just due to the anomalies of a lot of small file copies => but in any event it's pretty clear that these drives are working just fine, even with one used for parity.    The key thing is it didn't "freeze" (as some 3rd party tests have shown the drives can do for a while).    I'm sure your next post will be the final "Done" status for the copies ... not sure if you set it to auto-verify or not; but if you did, just for grins let that run as well -- just to confirm that these will be MUCH faster.

 

That increase in speed around 85% was a bit of a spike just as I took the screenshot. I monitored and it went back down to ~500KB/s straight away. I've just added another screenshot at ~89% to the post above to prove it. Next update in that post will be the last one!

 

And Yes I set it auto verify! Ill let it run.

Well, there we go. Small File Test has completed.

http://lime-technology.com/forum/index.php?topic=36749.msg373188#msg373188

Basically my observations are that the copy started at ~1MB/s and then "settled" on ~500KB/s. It fluctuated somewhat between 500KB/s and 1MB/s but those were only "bursts".

I had verify copy set and while it wasn't as quick as the larger files it was faster than the write. As the post indicates the verify read speed was sustained at ~5.5MB/s.

As was noted above I did NOT experience any "Freeze" of any kind - which was predicted could happen as the persistent cache once filled was cleared.

I think that whatever Seagate has done to mitigate the SMR technology it has been done excellently and it mitigates any observable write penalty we have been discussing and speculating about.

All in all - whether you've got your Unraid Array filled with Large (~5GB to ~40GB), Medium (~400MB to ~4GB) or Small (<=215KB) Files then I have observed and now reasonably expect this drive to behave on Par with the WD Red PMR drives I have in my Main Server.

Based on my testing and observations I believe these are Excellent Drives which I would recommend for anyone using Unraid as I (and I believe allot of others in the community) do. That goes for use as an Data or Parity Drive.

I will certainly be putting these drives in my Main Server as well as my Backup Server now. And will do so without fear.

I think my testing on these drives is done unless someone can put a good enough argument together to do more. c3 had suggested to see the impact of a full persistent cache, disabling the drives write cache with hdparm BUT I don't see the need to do that now. What I wanted to see is if during real world use I would experience any degraded performance from my WD Red PMR drives in normal use in an Unraid environment and I clearly have NOT experienced any of that.

Time to delete the crap from my Servers.

Happy Days.

Thank you for performing the tests and sharing the results.

Now its just a matter of drive reliability, that we wont know until a year or two in.

Thank you for performing the tests and sharing the results.

 

Now its just a matter of drive reliability, that we wont know until a year or two in.

No worries. Happy to contribute any way I can.

Yep. Agree. I am quietly confident as I tested the hell out of the drives before I deployed them and with the 3 yr warranty they come with coupled with the fact I have a FULL backup now I am not worried. If they fail they fail (all drives will anyway) and i'll RMA. If I get 3 years out of them before a fail and have to retire them Ill consider I have had my moneys worth - BUT I won't queue the Seagate sucks debate again! Read it too much! 

Does filesystem matter?

Reiserfs seems to have significant overheard in starting file writes... compared to, say, xfs.

 

On a fragmented reiserfs drive, I've had to wait for more than 30s just for a file copy to start. I'd imagine loads of small file operations are a nightmare.

 

No, not at all.  Once the drive is spinning, the operational power is very consistent.  Reiser can indeed take a moderately long time to "think" about file placement on relatively full drives (90-95% is typically where this starts to be an issue) -- the actual copy itself runs at full speed, but the initialization can indeed take a good while.    But this doesn't use any more power than a copy with any other file system.  [i suppose the purist view is that "well, it adds 30 seconds to the time before the drive will ultimately spin down" ... so from that perspective it indeed "wastes" power =>  about 2 watts for perhaps 30 seconds ... or 0.000002 kwh  ]

 

Pretty sure he is asking about the filecopy, and yes, filesystem does have an impact on file access time. As mentioned before, the test of 170,000 in one directory is very different that the test of 170,000 file spread across a directory structure X wide and Y deep. Also, the fragmented file (or directory) will impact access.

 

Ahh ... since it was buried in the midst of a lot of posts r.e. power consumption I was thinking in those terms.

 

As for whether it impacts the file write test Daniel is doing, I doubt it, as these drives are very sparsely populated (well under half full).  When you're writing a very large # of very small files they're always MUCH slower than writing large files -- almost certainly due to the directory overhead, which results in a LOT of seek and latency time for each write.  Plus, of course, the typical 4 I/O's per write to maintain parity.

 

... but certainly as a drive gets very full Reiser's write performance notably slows down => that's not a player her, however, as the drives are neither full nor Reiser.

Thanks guys. Yes, c3 was correct, it was in the copy performance context.

I guess i'll pick up a few of these myself. The cost advantage compared to 6tb drives is too much...

Daniel => Really appreciate the testing you've done with these.    Clearly you've proven that they work just fine for UnRAID ... even as parity (the use case where there was certainly some doubt).

While I certainly wouldn't want to use these drives for an application where there were significant random write operations from multiple users (i.e. a large database application);  you've shown that for an UnRAID server they work just fine.  My next server will absolutely be a set of either these or the forthcoming 10TB versions ... depending on just when I build the server.

In fact, I was talking to a friend yesterday who wants a small (10TB) server, and after our discussion he decided he'd just buy 3 of these drives, since he can build a 16TB system with just 3 drives.  His only reservation was whether or not your final test showed any issues. ... I just sent him a note and told him all was well => so I suspect we'll be putting his server together next week 

I think the verify part of Teracopy doesn't show actual speeds, it gets stuck at one "last measured" speed IIRC.

I confirmed that a while ago by looking at bwm-ng stats during the verify IIRC.

I think the verify part of Teracopy doesn't show actual speeds, it gets stuck at one "last measured" speed IIRC.

I confirmed that a while ago by looking at bwm-ng stats during the verify IIRC.

Interesting, do you have a reference for this? I ask only because this is not my experience as I have seen the reported read speed change very frequently.

I haven't seen TeraCopy "stuck" at a particular speed; but I have noticed that the reported speed during validation seems to frequently be a bit slower than it's actually achieving.  [but the statistics at the end of the validation are correct]

I'll install the latest beta and try it again.

Confirmed. The release version of Teracopy doesn't display the verify speed correctly at ALL.

The 3.x alpha does, but it looks horrendous. So, I won't be using that!

3.x alpha

Copy to SSD: ~50MB/sec write

Verify: (fluctates, which is correct) ~145MB/sec

2.3 release

Copy to SSD: ~50MB/sec write

Verify: 47MB/sec (stuck). Wrong.

It sticks at the last write speed. It doesn't show the actually verify (read) speed, so don't use those readings.

The startup current is all that matter when you are figuring out if your PSU has enough juice to power your hard drives. That was kind of my point, but I didn't make it very well! :-)

 

That spinup draw is crucial, because if there is not enough power, the drive(s) won't spin up.

This is one of the reasons I would always recommend purchasing a quality PSU and one that is at least %20-%30 more then what you think you would need. According to my watt meter I'm pulling approx 200 watts at idle and have an 800 watt power suppply. I never had power issues since I built the server. I'm amazed how good the Seasonic PSU's are. I also have a few EVGA G2's that are very good quality too.

Electricity costs are so spread out all over I can see why people want to spin down their drives. But for me to keep my box running 24/7 only costs $15/month or less. I have quite a few bitcoin miners that pull 600 watts each and run 24/7 so my unraid box is just a tiny little bit of my electric bill.

The startup current is all that matter when you are figuring out if your PSU has enough juice to power your hard drives. That was kind of my point, but I didn't make it very well! :-)

 

That spinup draw is crucial, because if there is not enough power, the drive(s) won't spin up.

 

This is one of the reasons I would always recommend purchasing a quality PSU and one that is at least %20-%30 more then what you think you would need. According to my watt meter I'm pulling approx 200 watts at idle and have an 800 watt power suppply. I never had power issues since I built the server. I'm amazed how good the Seasonic PSU's are. I also have a few EVGA G2's that are very good quality too.

 

Electricity costs are so spread out all over I can see why people want to spin down their drives. But for me to keep my box running 24/7 only costs $15/month or less. I have quite a few bitcoin miners that pull 600 watts each and run 24/7 so my unraid box is just a tiny little bit of my electric bill.

You two should probably head over to the PSU thread where you can find this years old guidance.

A good PSU for unRaid has the following:

 

1. Single 12 volt rail.  A subsequent figures refer to the 12 volt rail.

2. The minimum capacity that can power your build. Any more will just waste power. All drives will be in use during startup, shutdown, parity check, parity build, failed drive emulation, and drive rebuild, but startup requires the most power.

3. 2 amps (24 watts) per green drive and 3 amps (36 watts) per non-green drive on the 12 volt rail.

4. 5 amps (60 watts) for the motherboard on the 12 volt rail.

 

 

Please make comments below and I will incorporate changes in to this post.

I tend to do a bit more math and avoid spending on larger power supplies that run so low, efficiency becomes a concern.