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

[garycase]

...  I am 20% progress (to completion) away from concluding that these drives are FINE for my use in an UNRAUD environment.

 

I agree it's best to reserve judgement until the copy is actually done ["... It ain't over 'til the fat lady sings ..."] ... but it's pretty clear these drives work just fine in an UnRAID scenario.  You'd have to set up a very large set of random writes of very small files to multiple drives at once to force these outside of the "mitigated zone" that Seagate has done such a good job of => and that's simply NOT a likely scenario in UnRAID.   

 

 

...  The above also means I am 20% progress (to completion) away from using these drives in the refresh of my Main Server over my planned 6TB WD drives.

 

Ditto => Based on your experience my next server will use either these or the forthcoming 10TB versions of them -- NOT the 6TB WD Reds I was planning to use.

 

 

... I don't really subscribe to the whole "Seagate drives always fail and are generally less reliable". Generally my observations have led me to conclude that in the main those who have had drives fail (Seagate or otherwise) inside the warranty of the drive tend to be those who don't adequately "work out" their drives before deploying them OR operate them outside the manufacturers operating conditions (e.g. temperature)!

 

Agree completely.  The vast majority of drive failures I've seen have been either infant mortality [didn't pass my initial testing regimen, so I had them replaced]; or drives that have overheated ... not necessarily even outside of the specified operating range, but near the upper end of it.      If you ensure you have good airflow in your case, so the drive's run at modest temperatures; and ensure you keep the case relatively dust free (blow it out with compressed air a couple times/year), then your drives are likely to be VERY reliable.

 

Clearly ALL drives will eventually fail, but as long as you (a) have a complete set of backups; and (b) replace a failed drive promptly; it's VERY unlikely you'll ever lose any data.  The reliability of your overall SYSTEM is much more important than that of any one component ... and that reliability is significantly enhanced with good backups.

 

[garycase]

As for power ... you could measure this with a Kill-a-Watt in the US, but similar devices for 220v are harder to find and cost a good bit more.  Not sure what they sell in Australia.

 

However, I think it's fair to trust the manufacturer's specs on these ...

 

Seagate shows a typical operating power requirement of 7.5w, with idle power of 5.0w (this is spinning, but not actively reading/writing).  Standby is < 1.0w

 

By comparison, a 4TB WD Red has an operating power draw of 4.5w, idle of 3.3w, and standby is rated at 0.4w

 

So these drives draw about 50% more power when spinning, and 67% more power when I/O operations are ongoing, then the Reds, which are about as efficient a drive as you can get.    HOWEVER ... they hold twice as much data => so the power/TB is actually LESS than with the Reds      ... and in a typical UnRAID environment, most of the time drives are spun down, so they'll be drawing less than a watt [Again, they likely draw more than the Reds in the same state; but for a given total capacity you'd also only have about half as many drives].

 

Note:  The 6TB WD Reds draw 5.3w in operation, 3.4w when idle ... so these have a slightly better power/TB draw than the Seagates => but the reality is the power is plenty low enough to really not matter  :)

 

... I simply wouldn't let that be a factor in deciding whether or not to use the SMR drives.

 

 

 

[danioj]

How much power do they consume spun down, spun up, read/write etc?

 

As for power ... you could measure this with a Kill-a-Watt in the US, but similar devices for 220v are harder to find and cost a good bit more.  Not sure what they sell in Australia.

 

However, I think it's fair to trust the manufacturer's specs on these ...

 

Seagate shows a typical operating power requirement of 7.5w, with idle power of 5.0w (this is spinning, but not actively reading/writing).  Standby is < 1.0w

 

By comparison, a 4TB WD Red has an operating power draw of 4.5w, idle of 3.3w, and standby is rated at 0.4w

 

So these drives draw about 50% more power when spinning, and 67% more power when I/O operations are ongoing, then the Reds, which are about as efficient a drive as you can get.    HOWEVER ... they hold twice as much data => so the power/TB is actually LESS than with the Reds      ... and in a typical UnRAID environment, most of the time drives are spun down, so they'll be drawing less than a watt [Again, they likely draw more than the Reds in the same state; but for a given total capacity you'd also only have about half as many drives].

 

Note:  The 6TB WD Reds draw 5.3w in operation, 3.4w when idle ... so these have a slightly better power/TB draw than the Seagates => but the reality is the power is plenty low enough to really not matter  :)

 

... I simply wouldn't let that be a factor in deciding whether or not to use the SMR drives.

 

 

@pras1011: Thats good enough for me! Unless you can think of a reason I should run a test not addressed here - not going to bother! 

[garycase]

I don't see any reason to bother trying to get more detailed measurements.

 

If you happen to have a watt-meter that works with your power, you could note the power draw with all drives spun down; and then spin everything up and start a parity check, and see what the draw is then.    Clearly the difference divided by the # of drives would be close to the actual power the drives are drawing [but not exactly, since there's no way to know just how much extra power the CPU is drawing relative to its idle state].

 

You could do the same thing by noting the power draw from your UPS in the same two conditions ... assuming that your UPS has a display that shows the current draw (not all do).

 

[pras1011]

I use a kill a watt. For idle my power usage is 90watts and on parity check its 200 watts!

[pras1011]

Danioj. Would it be a good idea to do one big post with all the data that you have obtained so far?

[danioj]

Danioj. Would it be a good idea to do one big post with all the data that you have obtained so far?

 

You read my mind. I PM'd garycase only an hour or so ago about it - more about format and what to include and see if we can sticky it. Too much wine tonight to do it now and the latest test still has ~ 2 hours to run!

 

I'm on it though! I'll take the action!! 

[SSD]

I don't really subscribe to the whole "Seagate drives always fail and are generally less reliable". Generally my observations have led me to conclude that in the main those who have had drives fail (Seagate or otherwise) inside the warranty of the drive tend to be those who don't adequately "work out" their drives before deploying them OR operate them outside the manufacturers operating conditions (e.g. temperature)!

Everyone's personal experiences are different. I had two of two Seagate 2TB drives fail on me in scary ways (and that was after returning one of the two for replacement due to problems during its preclear). They were the worst of the worst if you look on BackBlaze. I bought 4 apparently white listed WD drives at a super price. Every one of them failed during preclear. All drives are not equal and it is smart to do research before investing hundreds or even thousands.

 

In contrast, I have a couple of Seagate 4TB drives in my array that got good marks on BackBlaze and were on a good sale, and they have worked quite well so far.  My older drives (which are now in my backup array) were mostly 1T WD and 2T Hitachis, with a few 2T WDs. The 1T WD's are running strong (only 1 failed), all of the Hitachi's are running strong, and 2 of 3 of the WD 2Ts failed. All of these drives are well over 5 years old.

 

We tend to value drives based on $/T, but what we may be more interested in is $/T/yr. If I have Hitachi's that last 7 years and cost $40/T, and Seagates that last 4 years and cost $35/T. Looking on an annual basis, the Hitachis cost $5.71 T/yr, and the Seagates cost $8.75/T/yr. I know there are no guarantees, but having gone through several drive replacement cycles, I certainty consider longevity!

 

IMO, drive brand AND MODEL should influence buying decisions, and if you want your drives to live a long life, HGST drives are consistently at the top of the reliability scores. The Seagates are looking promising, and I am considering investing, but for now I have enough space and would only jump at a great price.

 

Bottom line, it's a gamble whatever you buy, but odds are longer for some drives vs others.

[HellDiverUK]

All my stuff is now copied over to the pair of Archive v2 drives.  Took about 8 hours to copy ~3.8TB across gigabit.  I did notice the drives slowing up a little at various points, I assume while doing the shingling on parts of the drives formerly written to.  Once it got past that area (up to about 100GB) they ran just fine at ~100MB/s for big files.

 

I'm surprised how noisy the drives are on read/write, they rattle away like my HGST Deskstar NAS units, which are 7200rpm.  I've also witnessed them rattling away for several (up to 30) seconds after drive access has apparently finished by the host.  I assume it's SMR housekeeping in action.

 

Platter whine on the Seagates is totally absent, as quiet as a WD Red.  Lots quieter than the Hitachis, and quieter than the Seagate Desktop.15 by a little margin.  The D.15 units I have are shucked, so park their heads every few seconds, giving a wheeze-ka-boing-clunk! noise which gets pretty irritating pretty quick.

 

I'm 48 hours in with these drives and I've no regrets, other than the fact they're almost 50% full already. 

[garycase]

Danioj. Would it be a good idea to do one big post with all the data that you have obtained so far?

 

You read my mind. I PM'd garycase only an hour or so ago about it - more about format and what to include and see if we can sticky it. Too much wine tonight to do it now and the latest test still has ~ 2 hours to run!

 

I'm on it though! I'll take the action!! 

 

Just saw the PM about 15 min ago -- since the topic's already come up, I'll just reply here.    Definitely a good idea to start a new thread r.e. "Seagate 8TB Shingled Drives in UnRAID" with a good overview of what we've learned to date from various folks who already have them -- you've done by far the best set of overall testing on these that's helped to confirm the performance characteristics.    Between your tests, and the "under the hood" info that was gleaned by Storage Tech in their evaluations and testing, we now know a LOT about how these drives perform, and can make some very good educated guesses about just what situation might cause issues.

 

The key point is, of course, that they work VERY well for the bulk of uses "UnRAID'ers" will subject them to, so they're a very good choice for a high capacity system.

 

We're leaving tomorrow morning for 10 days, so I'll have very limited time to contribute to that thread, but I'll start it, pin it (sticky it), and add a few general thoughts today and let you fill in the blanks and add your performance data  [i'd just summarize the data and perhaps include a link to the sections in this thread where you were providing detailed status for those who want more details].

 

[garycase]

Here's the start of the "sticky" => I'll fill in the 2nd post later today.  Plan to outline the characteristics of Seagate's mitigations (persistent cache, buffer characteristics, and how the firmware appears to do the mitigations); provide a brief overview of the testing Daniel did;  and outline the ways I still think you COULD get write problems with the drives [Not really "problems" -- the writes would still work fine; they'd just be excruciatingly slow].

 

http://lime-technology.com/forum/index.php?topic=39526.0

[danioj]

 

Update:

 

80% into the copy: 3.05TB down of ~4TB. (19,000 files of 22,526) so far. Still speeding along at ~40MB/s.

 

 

 

In addition - I monitored the copy in the test of the ~4GB files and have done so in this test too. INTERESTING results! Where I saw periodic drops in speed as it reached 100% of 4TB of the larger files  I am now seeing INCREASES in speed as it is reaching 4TB of the smaller files up to ~59MB/s.

 

 

I am certain these speed fluctuations are not material as they do not impact the mean speed of the copy. But I find them interesting all the same.

 

For those who need more evidence:

 

 

P.S. I am 20% progress (to completion) away from concluding that these drives are FINE for my use in an UNRAUD environment. I have thousands of files all on average between 400MB and 15GB and between two copies of 4TB of sets of both I have experienced NO difference in write or read speed between these Seagate 8TB drives and my existing WD Red 3TB drives.

 

P.P.S. The above also means I am 20% progress (to completion) away from using these drives in the refresh of my Main Server over my planned 6TB WD drives.

 

Update. 100% complete and no drop in speed. ~40MB/s for ALL 4TB of the files.

 

Thats 2 tests now (1 test with ~4TB of LARGE Files of between 1.5GB and 15GB on average and peaking at about 40GB and 1 test with ~4TB of SMALLER Files of between 100MB and 400MB on average and peaking at about 2GB) in which I have NOT noticed any discernible dip in performance in these drives compared to my WD Red 3TB's.

 

I am now convinced that these drives are more than fine for how I use Unraid and my testing has led me to feel VERY confident that I am NOT going to experience any drastically slow speeds as a result of the SMR technology and the persistent cache implemented in these drives. So much so that I am not abandoning my plan to use WD PMR drives in my Main Server for these Seagate's (AUD $399 for a WD Red 6TB vs AUD $399 for a Seagate 8TB Archive which performs just the same in my use case - No Brainer).

 

As noted earlier I am working to put this all into a Sticky and bring it all together.

 

More than happy!

[johnsanc]

Fantastic results so far. I am considering buying a few of these, but it would be nice to see someone run another test with "small" files. I would consider the previous 2 tests as "large" and "medium". For example I have some arcade artwork that spans 170,000 files in about 35GB. If these drives can handle something like that then I think we have ourselves a winner.

[c3]

Fantastic results so far. I am considering buying a few of these, but it would be nice to see someone run another test with "small" files. I would consider the previous 2 tests as "large" and "medium". For example I have some arcade artwork that spans 170,000 files in about 35GB. If these drives can handle something like that then I think we have ourselves a winner.

Drives don't care what size files are, filesystems do.

[garycase]

Fantastic results so far. I am considering buying a few of these, but it would be nice to see someone run another test with "small" files. I would consider the previous 2 tests as "large" and "medium". For example I have some arcade artwork that spans 170,000 files in about 35GB. If these drives can handle something like that then I think we have ourselves a winner.

 

As long as you were writing these all sequentially, it's almost certain they'd be just fine.  You'd still see a notable slowdown in the copy speed due to the directory write overhead ... anytime you copy a large number of very small files you'll see this unless the directory writes are cached.    But this issue has nothing to do with the fact that the drives use shingled recording.    Note that even if you wrote these files at random locations, 35GB isn't much larger than the size of the persistent cache (25GB), so it's unlikely you'd fill it ... at least not until the very end of the copies.

 

[garycase]

Fantastic results so far. I am considering buying a few of these, but it would be nice to see someone run another test with "small" files. I would consider the previous 2 tests as "large" and "medium". For example I have some arcade artwork that spans 170,000 files in about 35GB. If these drives can handle something like that then I think we have ourselves a winner.

Drives don't care what size files are, filesystems do.

 

The drive doesn't know or "care" about the size of the files;  but it does track the size of the writes -- so if you're writing a single file then it implicitly does "care" about the size.  If the file is smaller than a shingled band it's going to either be written to the persistent cache OR, if the cache is full, require a band rewrite; whereas if it's larger than the band, the entire band will be written with no need for a rewrite.

 

But in the case mentioned here, if these files are all written sequentially, virtually all of the writes will be full band writes, with no band rewrites and little use of the persistent cache.  Nevertheless, the performance would still be significantly degraded due to the large number of files and the subsequent directory updates.  But as I mentioned in my post above, this slowdown has nothing to do with the SMR technology.

 

[c3]

Fantastic results so far. I am considering buying a few of these, but it would be nice to see someone run another test with "small" files. I would consider the previous 2 tests as "large" and "medium". For example I have some arcade artwork that spans 170,000 files in about 35GB. If these drives can handle something like that then I think we have ourselves a winner.

Drives don't care what size files are, filesystems do.

 

The drive doesn't know or "care" about the size of the files;  but it does track the size of the writes -- so if you're writing a single file then it implicitly does "care" about the size.  If the file is smaller than a shingled band it's going to either be written to the persistent cache OR, if the cache is full, require a band rewrite; whereas if it's larger than the band, the entire band will be written with no need for a rewrite.

 

But in the case mentioned here, if these files are all written sequentially, virtually all of the writes will be full band writes, with no band rewrites and little use of the persistent cache.  Nevertheless, the performance would still be significantly degraded due to the large number of files and the subsequent directory updates.  But as I mentioned in my post above, this slowdown has nothing to do with the SMR technology.

 

Nope.

 

The drive is not informed that these 2 blocks are for file A and these 4 blocks are for file B and these 4 blocks are for file C, just write these blocks. The drive only sees a stream of blocks, it has no idea if they are for one or more files. (Unless you are using the Seagate Kenetic). That's why you guess the persistent cache will help.

 

170,000 files in one directory is very different from 170,000 files in a directory structure X layers deep and Y wide.

 

Depending on filesystem, these writes may not be sequential at all. Depending on the filesystem and directory structure, there will be around 500,000 writes for this test case.

 

The usefulness of the Seagate SMR persistent cache with XFS can be impacted by the OS scheduler used. Last time I looked unRAID was using NOOP, which could make this a difficult task. NOOP is a simple FIFO queue in which reads/writes are not collected for optimization. Changing to DEADLINE would allow the OS to gather up to 5 seconds of writes before sending them to the device. Thus directory writes could be taken out of sequence and file writes gathered.

 

Filesystem awareness of SMR is new, but with BTRFS you could try the ssd-spread option. This might gather writes.

 

This type of data is why filesystems like Haystack are used.

 

[garycase]

That's what I said -- i.e. "... just write these blocks ..."  is  the same as "... it does track the size of the writes."

 

I specifically noted that "... the drive doesn't know or "care" about the size of the files."

 

It's true, of course, that if the filesystem scatters the files around on the disk, the writes may not all be sequential; but it's very unlikely that's the case ... especially for a large number of very small files.

 

Nevertheless, I agree it would be nice to have an actual test of a write with a very high number of files that collectively exceed the size of the persistent cache.    We've already seen that with modest and large file sizes there's no problem with Seagate's mitigations => but the results COULD be a bit different with something like was proposed here.    The write structure would indeed be very different in one key aspect => the constant head movement between the file location and the directory location may confuse the drive's algorithms and result in it not recognizing that the files are sequential (assuming they are).  I'd think that the time differential between writes, even with the directory seek/write cycle, would still be small enough that the drive's firmware would recognize that the files were filling a band, but that MIGHT not be the case.

 

... and if not, this could result in most of the files being written to the persistent cache ... and of course if that was to get full the write speeds would become abysmal.  I don't think 35GB is enough above the 25GB size of the cache for this to be very likely; but it's certainly possible.

 

[danioj]

Fantastic results so far. I am considering buying a few of these, but it would be nice to see someone run another test with "small" files. I would consider the previous 2 tests as "large" and "medium". For example I have some arcade artwork that spans 170,000 files in about 35GB. If these drives can handle something like that then I think we have ourselves a winner.

 

I just don't have that many files of the size you mention. I would be happy to test a set of files of the size you want and then post results.

 

Maybe there is a "file generator" I can use. I am SURE there is, just need a good quick one. Ill have a look.

 

I could then create 35GB made up or 170,000 files and test for you.

[johnsanc]

The exact size or number of files for the test doesn't really matter to me. I was just providing my own worst case scenario on my own array. Interestingly these files probably are scattered on one of my disks because I initially downloaded them via a torrent, so their initial creation was not sequential.

 

However if you need a bunch of semi random small files just download a few of these packs and copy it a few times: http://www.progettosnaps.net/snapshots/

 

 

[danioj]

Fantastic results so far. I am considering buying a few of these, but it would be nice to see someone run another test with "small" files. I would consider the previous 2 tests as "large" and "medium". For example I have some arcade artwork that spans 170,000 files in about 35GB. If these drives can handle something like that then I think we have ourselves a winner.

 

I just don't have that many files of the size you mention. I would be happy to test a set of files of the size you want and then post results.

 

Maybe there is a "file generator" I can use. I am SURE there is, just need a good quick one. Ill have a look.

 

I could then create 35GB made up or 170,000 files and test for you.

 

OK - I found one. http://www.7tutorials.com/3-ways-create-random-dummy-files-windows-given-size. Not tested it yet but should be simple enough.

 

... and if not, this could result in most of the files being written to the persistent cache ... and of course if that was to get full the write speeds would become abysmal.  I don't think 35GB is enough above the 25GB size of the cache for this to be very likely; but it's certainly possible.

 

Lets try and test this once and for all and find the threshold. We ALL "know" at some point the writes are going to slow down - I think we are all just looking for a real world example of when and under what scenario.

 

So what do people think of 50GB of "small" files? What do we really define as "small"?  (The man said to his wife .. )

[danioj]

The exact size or number of files for the test doesn't really matter to me. I was just providing my own worst case scenario on my own array.

 

Just weigh in my friend. This is all for the community so by knowing your scenario we can best get some supportive data and results.

 

Interestingly these files probably are scattered on one of my disks because I initially downloaded them via a torrent, so their initial creation was not sequential.

 

I dont "Think" it matters how they were created (sequentially or not) it matters how they are written.

 

However if you need a bunch of semi random small files just download a few of these packs and copy it a few times: http://www.progettosnaps.net/snapshots/

 

Ta, Ill have a look!

[c3]

So what do people think of 50GB of "small" files? What do we really define as "small"?  (The man said to his wife .. )

 

These days, the average filesize given (215k) is considered small. 50GB would 243,854 files.

 

You could stick to the case mentioned, 170,000 files of 215kb each. But the directory structure will have a significant impact. 170 directories of 1,000 files is different that one directory of 170,000 files.

 

In the use case of unRAID, you could leverage split level to gain access to more cache.

[danioj]

So what do people think of 50GB of "small" files? What do we really define as "small"?  (The man said to his wife .. )

 

These days, the average filesize given (215k) is considered small. 50GB would 243,854 files.

 

You could stick to the case mentioned, 170,000 files of 215kb each. But the directory structure will have a significant impact. 170 directories of 1,000 files is different that one directory of 170,000 files.

 

In the use case of unRAID, you could leverage split level to gain access to more cache.

 

I could use this: http://dottech.org/116607/windows-review-filetool-program/

 

Set the file size to 215k and about 50 folders for 500MB and then spend some time doing some copying and pasting down about maybe 20 levels up to 30-50GB?

[johnsanc]

I'm not sure if it matters much, but I think the test should have varying filesizes instead of everything being 215k. If anything its just a truer representation of a real world scenario.