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

[garycase]

@garycase so, would you expect to see a slow down if you queued 12TB of data to transfer to an Unraid Array comprising 2 of those drives in one go?

 

No, not if the cache is 25GB.  But once that cache was full, I suspect write performance will degrade markedly.  As bjp999 noted, it would almost certainly NOT be a good cache disk ... and if you do a lot of writing to your array at once it would also be a poor choice for a parity drive.    But I'd think it's just fine for data drives.

 

[danioj]

So, in my case where I am transferring 12TB at once - what do you think? Transfer to an array (containing these drives) not protected by Parity initially then once everything is backed up the first time add a Parity drive and calculate Parity? Would that help do you think?

 

Following the initial backup I cant imagine Ill be transferring more than 25GB per week to the backup.

[pras1011]

The big question is how reliable is seagate.

[garycase]

...

Following the initial backup I cant imagine Ill be transferring more than 25GB per week to the backup.

 

The actual cache for the Seagate drive is 128MB -- that's 1/200th of the 25GB jtown noted.  But that 25GB may be  correct for the "persistent cache" on the drive -- an area on the outer cylinders that is used to hold remapped cylinders that have not yet been actually written to their actual location within a shingled band.  I'm not sure where jtown saw that number, but it seems reasonable.

 

The UseNix presentation referenced by jtown shows this process quite nicely, and the presenter does a pretty good job of outlining the technology and the workarounds used to allow random writes (which would otherwise effectively not be supported with shingled drives).

 

I'd suggest watching the entire presentation to get a good feel for the overall characteristics that can be anticipated with the SMR drives, but I'll make a few observations ...

 

=>  The Seagate 5TB drive has an outer cylinder band size of 36MB, which becomes smaller as you move towards the inner cylinders.  I assume the 8TB drive is similar (although possible a bit larger initially).    I ASSUME ... but do not know this for a fact ... that since the band is notably smaller than the drive's memory cache (128MB), that the firmware recognizes when a series of writes covers an entire band, and simply writes that entire band directly, without any writes to the persistent cache.  [This would explain why pre-clears work well].

 

=>  The key performance degradation with these drives is with random writes, which would be VERY slow without some mitigation.    That's where the persistent cache (an area on the disk separate from the memory cache) comes into play.    Random writes are written to the persistent cache, with a cache map maintained, which is checked before any reads, so any sector that's been modified but not yet written to its actual location will be read from the persistent cache.    This helps give MUCH better random write performance, at the cost of some read performance degradation, since "sequential" reads may actually not be sequential, as the drive has to seek to the persistent cache to get any of the modified sectors in the read.

 

=>  According to the presenter in the UseNix presentation, it generally takes about 15 minutes worth of writes to fill the persistent cache  [i assume this does not count any writes that cover an entire band, assuming I'm correct that the firmware would recognize these and write them directly to the correct area].    But if you do enough random writes that the persistent cache is filled, performance will come to a screeching halt ... the presenter didn't really address just how bad it could be, except to note that it could potentially take HOURS for everything to "catch up."

 

 

To answer your specific question:  If your writes are limited to 25GB at a time, and IF the persistent cache on the 8TB Seagate is 25GB (or larger); then you should be fine.    In fact, if you're writing large media files, and IF I'm correct about full band writes being recognized and bypassing the persistent cache area, then you could write a lot more before there would be performance issues.

 

One thing the presentation makes pretty clear is that write performance CAN be VERY POOR if you do enough random writes to fill the persistent cache.    They've done a nice job of mitigating the technology to allow these to "seem" like typical drives ... but if you hit the "wall" of the persistent cache size, they will effectively freeze for further writes for quite some time.    The presentation certainly convinces me that I do NOT want one of these drives for my parity drive; but it should be fine for a data drive.

 

 

[c3]

Only thing not mentioned is volatile write cache needs to be enabled to bypass persistence cache.

[Yousty]

One thing the presentation makes pretty clear is that write performance CAN be VERY POOR if you do enough random writes to fill the persistent cache.    They've done a nice job of mitigating the technology to allow these to "seem" like typical drives ... but if you hit the "wall" of the persistent cache size, they will effectively freeze for further writes for quite some time.    The presentation certainly convinces me that I do NOT want one of these drives for my parity drive; but it should be fine for a data drive.

 

So my question is, if somebody is using a cache drive in their unraid server like I am and just have mover run nightly (transferring anywhere between 1GB and 50GB in various file sizes per day), will I see issues with having this 8TB drive as my parity?

[jtown]

I'm not sure where jtown saw that number, but it seems reasonable.

 

It's in the PDF linked above the video.  Lots of diagrams, graphs, and tables.  The 25 gig figure is towards the end just before the "Conclusions" section.

[pkn]

Wow. Reads like a detective story. So, now it's not just smart writing management, it's a 25 GB "persistence cache"... working essentially the same way as unRAIDs cache drive with Mover...

[nightanole]

One thing the presentation makes pretty clear is that write performance CAN be VERY POOR if you do enough random writes to fill the persistent cache.    They've done a nice job of mitigating the technology to allow these to "seem" like typical drives ... but if you hit the "wall" of the persistent cache size, they will effectively freeze for further writes for quite some time.    The presentation certainly convinces me that I do NOT want one of these drives for my parity drive; but it should be fine for a data drive.

 

So my question is, if somebody is using a cache drive in their unraid server like I am and just have mover run nightly (transferring anywhere between 1GB and 50GB in various file sizes per day), will I see issues with having this 8TB drive as my parity?

 

You would have to write for 15min about 25 gigs of random writes to have poor performance.  Sequential data is written to the drive itself in one big lump, only random stuff is written to the persistence cache, and then put on the real drive once its ready.  So yea as long as; everything is done via mover, or you are writing directly to the array for less than 15min for random, you are good.  Just dont make a mysql server and dump a huge database to it and you will be good.

[garycase]

One thing the presentation makes pretty clear is that write performance CAN be VERY POOR if you do enough random writes to fill the persistent cache.    They've done a nice job of mitigating the technology to allow these to "seem" like typical drives ... but if you hit the "wall" of the persistent cache size, they will effectively freeze for further writes for quite some time.    The presentation certainly convinces me that I do NOT want one of these drives for my parity drive; but it should be fine for a data drive.

 

So my question is, if somebody is using a cache drive in their unraid server like I am and just have mover run nightly (transferring anywhere between 1GB and 50GB in various file sizes per day), will I see issues with having this 8TB drive as my parity?

 

Given that usage scenario you should be fine.

 

Since you're using a cache drive, your writes are NOT to the array, but to your cache drive -- so you'll "see" excellent write performance, just as you do now (assuming you have a cache drive now).

 

When the mover runs, it's possible -- if you've written close to the 50GB point that day -- that the writes will fill the persistent cache; but it even if that happens it will simply take longer for the moves to complete.  Since this is happening at "off hours" when you likely aren't using the server (and I suspect don't care just how long it takes) it won't make any real difference.

 

 

[garycase]

I'm not sure where jtown saw that number, but it seems reasonable.

 

It's in the PDF linked above the video.  Lots of diagrams, graphs, and tables.  The 25 gig figure is towards the end just before the "Conclusions" section.

 

Thanks -- I'd missed that.    I downloaded all the slides and watched the presentation, but had missed the additional info in that PDF.

 

Overall, it seems like Seagate has done a good job of mitigating what would have otherwise been very poor write performance for these drives.    As long as they're used in systems that won't "hit the wall" of a full persistent cache without time for it to clear they should work reasonably well.

 

[superloopy1]

I've got a pair arriving soon. So ... can i get this right. The concensus is NOT to use these drives as parity, yes? I have no cache drive.

 

[garycase]

I would not use them as the parity drive -- especially when there's no cache drive.

 

However, if you don't write over 25GB at a time to your array, the persistent cache on the drive should mitigate write issues ... and as long as there's a reasonable amount of "clearing time" for the cache to be emptied it would perform okay even as a parity drive.

 

The best setup would be to use a non-shingled "drive" (which could be a RAID-0 array) for your parity drive.

 

[danioj]

I like going to bed an waking up to this stuff!

 

Based on what I'm reading I think I'm convinced that if I tried to fill two of these bad boys in one queued job to back up (Archive) my exisiting 12TB Array then I'd see slower speeds. In the future however when backups are more progressive (ie weekly changes) then not.

 

Question is - do I care? Don't think I care about the possibility of slow performance weekly as the Arrays are sync'd but I'm not sure I like the idea of waiting weeks while the 12TB Array is backed up initially!!

[Yousty]

You would have to write for 15min about 25 gigs of random writes to have poor performance.  Sequential data is written to the drive itself in one big lump, only random stuff is written to the persistence cache, and then put on the real drive once its ready.  So yea as long as; everything is done via mover, or you are writing directly to the array for less than 15min for random, you are good.  Just dont make a mysql server and dump a huge database to it and you will be good.

Given that usage scenario you should be fine.

 

Since you're using a cache drive, your writes are NOT to the array, but to your cache drive -- so you'll "see" excellent write performance, just as you do now (assuming you have a cache drive now).

 

When the mover runs, it's possible -- if you've written close to the 50GB point that day -- that the writes will fill the persistent cache; but it even if that happens it will simply take longer for the moves to complete.  Since this is happening at "off hours" when you likely aren't using the server (and I suspect don't care just how long it takes) it won't make any real difference.

Thank you both for the replies. I had figured this drive would be fine as a parity used in conjunction with a cache drive based on everything I had read in this thread, but just wanted to make sure. I have a 256GB SSD as my cache drive and I've set up mysql to only use the cache drive so the only time data is ever being written to the array for my unraid server is at 3:30am when the mover script runs.

 

Now that you guys have cleared that up for me, looks like it's time to order one of these bad boys!

[jtown]

I've got a pair arriving soon. So ... can i get this right. The concensus is NOT to use these drives as parity, yes? I have no cache drive.

 

I'm using it as a parity drive right now with no performance hit.  In fact, it seems to run a smidge (1-2MB/s) faster.  Low 30s to mid 30s when writing to 4tb drives in the array.  My writes are generally files of half a gig or larger, usually in groups of under 15 gigs.  I've done a few 60 gig bundles of 2-2.5 gig files with no drop in write speed.

 

Edited to add:  I don't have a cache drive.

[garycase]

... My writes are generally files of half a gig or larger, usually in groups of under 15 gigs.  I've done a few 60 gig bundles of 2-2.5 gig files with no drop in write speed.

 

It sounds like virtually all of your writes are files that are larger than the band size, so the majority of those files will result in direct writes to a full band without involving the persistent cache (except possibly for the first few sectors and last few sectors of the files).  With this write pattern, you're very unlikely to fill the persistent cache with "bundles" of only 60GB or so.    It really does seem like Seagate's mitigation technique works very well at overcoming the very poor random write speed for the shingled bands ... masking it in a way that makes it almost completely invisible in many applications.

 

[BRiT]

I'm impressed with Seagate's mitigation of the performance issues. The band of non-shingled write bands is a rather straight-forward and simplistic means of alleviating the negatives of SMR.

 

It indirectly reminds me of how the first SSDs had spare pre-erased flash cells that could be used for when blocks had to be rewritten.

 

I now have this crazy idea of having a hybrid SMR drive using a 40GB SSD to serve as the non-shingled cache area.

[jtown]

I'm impressed with Seagate's mitigation of the performance issues. The band of non-shingled write bands is a rather straight-forward and simplistic means of alleviating the negatives of SMR.

 

It indirectly reminds me of how the first SSDs had spare pre-erased flash cells that could be used for when blocks had to be rewritten.

 

I now have this crazy idea of having a hybrid SMR drive using a 40GB SSD to serve as the non-shingled cache area.

 

Doesn't seem crazy at all.  Seagate's been doing "SSHD" hybrids for years, tho their solid state side is only 8 gigs.  And they switched from SLC to MLC on the last generation.  But they've definitely got the ability to make it happen.

[garycase]

In fact I wouldn't be at all surprised if the next generation of shingled drives uses an SSD as the persistent cache instead of a band on the drive itself.    That would eliminate the read penalty when reading sectors that had been rewritten to the cache but not yet moved to their actual location; and would actually make random writes faster than writes to a full shingled band.

 

[pkn]

First cycle of preclearing (via USB 3.0 card) of two 8TB Seagate externals comleted yesterday... times are:

 

... Total time 110:43:15

... Pre-Read time 27:06:35 (81 MB/s)

... Zeroing time 29:31:16 (75 MB/s)

... Post-Read time 54:03:47 (41 MB/s)

 

... Total time 110:31:16

... Pre-Read time 27:05:04 (82 MB/s)

... Zeroing time 29:24:42 (75 MB/s)

... Post-Read time 53:59:53 (41 MB/s)

 

Third drive (or rather replacement) has arrived today. Looking at this numbers I'm in serious doubt that I will have enough patience to run three preclearing cycles as planned... almost five days for single cycle!

[garycase]

You may want to just set the new drive for 2 cycles ... then all of them will finish on the same day 

 

Have patience ... better to find infant mortality issues NOW before you put them to use in your server.

 

Personally, I'd have just done 2 cycles ... but it's really not that big of a deal at this point, since you just got the 3rd drive.    The other 2 will finish their 3rd cycles about the same time the new one will finish 2.

 

[jtown]

I got faster preclear times on a SATA port.  About 76 hours per cycle.  (I lysdexic'd that as 67 on my earlier post.)  If you're going to shell the drives, may as well do it that way.  Tho I ran Seagate's full diagnostic before taking it out of the case and voiding my warranty.  That was about a half day process.  So figure 10 days or so for a pre-shelling diagnostic via USB3 then three preclears on SATA.

[garycase]

Clearly a direct SATA connection will give better times than the USB3 connection.

 

But once you've shucked the drive you've voided the warranty, so I can understand the desire to simply do it in the case.    It does, however, take ~ 4 extra days to do it that way 

[garycase]

... Just consider those extra days as the price of early "availability" via shucking.    And since you're voiding your warranty, you DO want to be pretty thorough in the testing.

 

Personally, I don't want to lose the warranty coverage -- as I noted when I commented earlier about the availability of these drives:

 

Actually I haven't seen any that are in-stock for consumers yet.    The only way to get one right now is to "shucking" the drives from external enclosures -- a practice many of us choose to avoid due to warranty concerns.