Oh, I thought these 10pTB drives were HGST drives.

 

They are.  But they use shingled recording technology (SMR) ... this technology has significantly lower write performance than standard perpendicular magnetic recording (PMR), so the write performance on the HGST 8TB helium-filled units (which use PMR) will be notably better than on the 10TB SMR units.    The Seagate 8TB units use SMR, so they have the same write performance issue.

 

 

Perfectly explained. Thank you.

 

I think for a backup server the SMR (if sufficiently cheaper to make a difference) drives will be fine as I'll never be in a position to experience the writes - even without a cache drive.

 

If I ever move them into my production box i guess I'll just have to ensure this issue is always mitigated by a cache drive.

Why will these not be good for parity drives?

Why will these not be good for parity drives?

most likely worse for parity than for data drives since the parity drive is updated on each and every writes to the array instead of just to the single data drive.

I didn't understand that explanation.

I didn't understand that explanation.

Writes to shingled drives are worse than normal drives.

The parity drive will always be written to.

I didn't understand that explanation.

 

Read through the thread -- the write issues with shingled drives are discussed several times.  Basically, when you write to a shingled drive, all of the "shingles" in the current zone need to be re-written, so writes are appreciably slower than with standard PMR drives.    That's why the Seagate drives are marketed as "Archive Drives" ... and Western Digital/HGST note that their high-capacity SMR drives are best used for archives as well.

 

If your system never has multiple simultaneous writes, then an SMR drive as parity wouldn't be so bad ... if you're using them for data drives, then there wouldn't be any appreciable change in performance with an SMR parity drive.    But if you have simultaneous writes (e.g. either multiple users; multiple PC's; or applications on UnRAID ... e.g. Dockers ... that write to the array) then having a relatively slow parity drive will result in an appreciable degradation of the array's performance.    In short, it's MUCH better to have a non-shingled drive as parity.

 

Truth is we don't know. No one is using them yet. Academically we can make arguments that an 8G SMR parity drive might become a bottleneck when processing multiple writes, or when writing to non-SMR drives in the array. But, for me, density wins out over speed and to be able to get a slower 8T disk for the same price or less than a faster 6T disk, I would go with the bigger one. But the key is reliability - and we have no data on the reliability of these drives. I have to believe that the BackBlaze's of the world are looking at these large drives and that data will emerge over time.

 

I am holding off for now, but if I was setting up a new array and these were price competitive, 3 8T drives would certainty be tempting. That would provide 16T of usable space. If parity was any sort of problem, I could then add a controller for a RAID0 parity pair (e.g., 2x 4T). Whenever a user sets up a new array, they have to convince themselves that it is solid and they trust it for their data (not just the drives, but the whole solution including motherboard, controllers, memory, and unRAID software). Once a thorough burn-in is completed and the drives have problem themselves reliable, it would be ready for use.

I didn't understand that explanation.

 

Read through the thread -- the write issues with shingled drives are discussed several times.  Basically, when you write to a shingled drive, all of the "shingles" in the current zone need to be re-written, so writes are appreciably slower than with standard PMR drives.    That's why the Seagate drives are marketed as "Archive Drives" ... and Western Digital/HGST note that their high-capacity SMR drives are best used for archives as well.

 

If your system never has multiple simultaneous writes, then an SMR drive as parity wouldn't be so bad ... if you're using them for data drives, then there wouldn't be any appreciable change in performance with an SMR parity drive.    But if you have simultaneous writes (e.g. either multiple users; multiple PC's; or applications on UnRAID ... e.g. Dockers ... that write to the array) then having a relatively slow parity drive will result in an appreciable degradation of the array's performance.    In short, it's MUCH better to have a non-shingled drive as parity.

 

Though if you use a cache drive for your app directories, and cache all of your user writes to the cache drive isn't this a moot point?

 

Couldn't this be surmised by saying... these are great with a Cache drive, and not so great otherwise?

Is this a guess that's it going to be bad or is there some testing data showing that it's bad?

Is this a guess that's it going to be bad or is there some testing data showing that it's bad?

It is not a guess. It's based on the science of the technology between SMR and PMR hard drives.

 

It's right there in their product specifications and white papers on how shingled (SMR) drives operate. They have to do more steps to do even a basic write, there is no getting around that.

Well it is because no one has tried it out on a unraid server. Yet. I will get buy one providing they are £165.

Well it is because no one has tried it out on a unraid server. Yet.

 

Sure, if you want to take the approach that science doesn't matter.

 

Their product sheets even designate their primary use as being archival instead of random updates.

... Though if you use a cache drive for your app directories, and cache all of your user writes to the cache drive isn't this a moot point?

 

Yes, if you have a cache for your apps and all writes to the array the speed of the actual writes to the protected array is indeed effectively moot.

 

Well it is because no one has tried it out on a unraid server. Yet. I will get buy one providing they are £165.

 

As noted above, it's certainly NOT just because nobody's tried one.    The technology simply requires far more time for writes than conventional PMR tracks, since EVERY track in a group of shingles has to be re-written when you write new data.    To mitigate this, the shingles are broken into bands of shingles ... if this wasn't done the entire disk would need to be rewritten when you wrote a single new sector !!    There's a reason the manufacturers market these drives for archival purposes, where write performance is far less important. [Note the picture of the drive in the very first post in this thread -- the drive is clearly labeled "Archive HDD"]

 

Having said that, it's certainly true that even a relatively slow SMR drive may have acceptable performance for many UnRAID applications -- indeed many of these servers are effectively archival anyway ... and the read performance of these drives isn't impacted by the SMR technology.

 

 

Well it is because no one has tried it out on a unraid server. Yet. I will get buy one providing they are £165.

 

As noted above, it's certainly NOT just because nobody's tried one.    The technology simply requires far more time for writes than conventional PMR tracks, since EVERY track in a group of shingles has to be re-written when you write new data.    To mitigate this, the shingles are broken into bands of shingles ... if this wasn't done the entire disk would need to be rewritten when you wrote a single new sector !!    There's a reason the manufacturers market these drives for archival purposes, where write performance is far less important. [Note the picture of the drive in the very first post in this thread -- the drive is clearly labeled "Archive HDD"]

 

Having said that, it's certainly true that even a relatively slow SMR drive may have acceptable performance for many UnRAID applications -- indeed many of these servers are effectively archival anyway ... and the read performance of these drives isn't impacted by the SMR technology.

 

Is it possible that, when doing sequential writes, and given that a memory cache is involved, that the write to the band of shingled sectors would only physically write to the drive once, thus minimizing the performance hit?

Well it is because no one has tried it out on a unraid server. Yet. I will get buy one providing they are £165.

 

As noted above, it's certainly NOT just because nobody's tried one.    The technology simply requires far more time for writes than conventional PMR tracks, since EVERY track in a group of shingles has to be re-written when you write new data.    To mitigate this, the shingles are broken into bands of shingles ... if this wasn't done the entire disk would need to be rewritten when you wrote a single new sector !!    There's a reason the manufacturers market these drives for archival purposes, where write performance is far less important. [Note the picture of the drive in the very first post in this thread -- the drive is clearly labeled "Archive HDD"]

 

Having said that, it's certainly true that even a relatively slow SMR drive may have acceptable performance for many UnRAID applications -- indeed many of these servers are effectively archival anyway ... and the read performance of these drives isn't impacted by the SMR technology.

 

Is it possible that, when doing sequential writes, and given that a memory cache is involved, that the write to the band of shingled sectors would only physically write to the drive once, thus minimizing the performance hit?

 

Clearly they do what they can to mitigate the impact, but the simple fact is that the drive needs to (a) read the old data from every shingled track involved; rewrite that data; and do this for as many tracks as are involved in the shingled band.  Each of these operations involves a rotation of the drive.  So while the write process is probably done fairly efficiently (i.e. not a lot of extra seek time involved, since once the process starts every track is adjacent), it still takes a lot of drive rotations.    Not sure what the rotational rate is for these drives, but if you assume 5900rpm that's about 10ms/rotation ... so a write that might take 15ms or so on a PMR drive (figure 5ms seek plus one rotation) will take many times that on an SMR drive ... figure the same 15ms plus an extra 10ms for every involved shingle.  I don't know how many shingles/band they're using ... but I assume it's at least a half dozen or so -- which would put the time to complete a write cycle in the 60ms or more range.

 

I assume these drives will cache a lot of that data, so for a sparse number of writes (where all the data fits in the drives buffers) the impact will be mitigated by the physical write activity being isolated from the user ... but with an active stream of writes this won't help once the cache is full, so the additional overhead will have a notable impact.

 

 

 

 

Clearly they do what they can to mitigate the impact, but the simple fact is that the drive needs to (a) read the old data from every shingled track involved; rewrite that data; and do this for as many tracks as are involved in the shingled band.  Each of these operations involves a rotation of the drive.  So while the write process is probably done fairly efficiently (i.e. not a lot of extra seek time involved, since once the process starts every track is adjacent), it still takes a lot of drive rotations.    Not sure what the rotational rate is for these drives, but if you assume 5900rpm that's about 10ms/rotation ... so a write that might take 15ms or so on a PMR drive (figure 5ms seek plus one rotation) will take many times that on an SMR drive ... figure the same 15ms plus an extra 10ms for every involved shingle.  I don't know how many shingles/band they're using ... but I assume it's at least a half dozen or so -- which would put the time to complete a write cycle in the 60ms or more range.

 

I assume these drives will cache a lot of that data, so for a sparse number of writes (where all the data fits in the drives buffers) the impact will be mitigated by the physical write activity being isolated from the user ... but with an active stream of writes this won't help once the cache is full, so the additional overhead will have a notable impact.

 

The reads and rotational delays are the same as faced today since reads are not slowed by SMR, only writes. And if the writes are effectively cached so as to minimize rewriting the same shingled band over and over, then sequential writes may not be slowed down much if at all.

 

All this means is that we don't really know what impact having this drive as parity will be until we see one in action. Which I think is what I said about 10 posts down.

The reads and rotational delays are the same as faced today since reads are not slowed by SMR, only writes.

 

... as I've said many times 

 

... and the read performance of these drives isn't impacted by the SMR technology.

 

 

...  And if the writes are effectively cached so as to minimize rewriting the same shingled band over and over, then sequential writes may not be slowed down much if at all.

 

Simply not true.  Even if all the data is cached, the shingled band still needs to be re-written.  Unless you're writing less data than fits in the drive's cache, this will have a very notable impact on the write times.  As I've also noted, if you're only writing small amounts of data that all fits in the drive's cache, then it's true that this extra time may be "hidden" from the user as the drive takes care of it after the write has already been acknowledged.  But for typical UnRAID use, where large media files are involved, that's simply not going to be the case.

 

 

All this means is that we don't really know what impact having this drive as parity will be until we see one in action. Which I think is what I said about 10 posts down.

 

We don't know the full extent of the impact; but we KNOW there will be a significant impact on the write performance relative to non-SMR drives.    As I've also noted throughout this thread, whether that's significant depends on two fundamental things:  (1)  Whether or not there are simultaneous writes being done (i.e. from multiple sources or via add-ons/Dockers that are doing array writes); and (2) whether the data drives are also SMR units.    If the data drives are SMR drives, and there are NOT simultaneous writes, then there's no reason not to use an SMR as parity, since its performance will match the data drives.      What's also clearly true is that the impact can be completely mitigated by simply using a cache drive for all array writes and as storage for any add-ons/Dockers.    As long as the cache drive is large enough that will completely isolate the actual write times from the user.

 

 

Simply not true. 

 

It is hard to argue facts when the facts are not in. This is your opinion.

 

Even if all the data is cached, the shingled band still needs to be re-written. Unless you're writing less data than fits in the drive's cache, this will have a very notable impact on the write times.  As I've also noted, if you're only writing small amounts of data that all fits in the drive's cache, then it's true that this extra time may be "hidden" from the user as the drive takes care of it after the write has already been acknowledged.  But for typical UnRAID use, where large media files are involved, that's simply not going to be the case.

 

How many times to you think that the drive is going to have to do a rewrite of the same block for a sequential write? Twice? Four times? 16? In order for this to work faster than a floppy disk, the programmers would have to figure our ways to avoid all the overwrites. I expect they will have done a better job than you are giving them credit for. I expect sequential write performance to be pretty good, but that random performance is gonna suck. But since 99% of unRAID writes are sequential, I think it won't be a big hit for most unRAIDers.

 

We don't know the full extent of the impact; but we KNOW there will be a significant impact on the write performance relative to non-SMR drives.

 

Significant impact? Don't know what that means. 10% slower, 25% slower, 50% slower, 90% slower?

 

What's also clearly true is that the impact can be completely mitigated by simply using a cache drive for all array writes and as storage for any add-ons/Dockers.    As long as the cache drive is large enough that will completely isolate the actual write times from the user.

 

It might help with "apparent" performance, but using it has a big negative. Data is not protected by redundancy until it is copied to the protected array. I do not use cache drives for this reason. I'd rather lose performance. And you have to pay the piper overnight, and if the drives are as slow as you are predicting, might not be completed by the time the next day comes!

Read the specs, they are rated 150MB/sec average read/write and max 190MB/sec read, both exceed your typical unRAID 1gbe.

I expect they will have done a better job than you are giving them credit for. I expect sequential write performance to be pretty good, but that random performance is gonna suck. But since 99% of unRAID writes are sequential, I think it won't be a big hit for most unRAIDers.

 

Actually I give the manufacturers a lot of credit for doing a pretty good job of optimizing this process.  I'd expect that the firmware is almost certainly optimized to minimize the rewrites within a band when sequential writes to the same band are done.    But unless you're writing the entire band, there will still be some set of tracks that need to be "picked up" (e.g. read before the write) and then rewritten [AND the drive would somehow have to "know" that you were going to write the entire band].    How extensive this is depends on the width of the bands ... if they're X tracks wide the drive may need to read and rewrite (X-1) additional tracks.  I suspect X is a relatively small number, as otherwise the write performance could be abysmal.

 

 

How many times to you think that the drive is going to have to do a rewrite of the same block for a sequential write? Twice? Four times? 16?

...

Significant impact? Don't know what that means. 10% slower, 25% slower, 50% slower, 90% slower?

 

Clearly that depends on the width of the bands.  If the entire disk was a single shingled band, a write to one sector could actually require re-writing the entire disk !!  I suspect the bands are fairly nominal, but really don't know.  But what's clear from the literature on this technology is that rewriting a sector on a track that has been "shingled over" (i.e. is part of a shingled band of tracks) cannot be done without overwriting subsequent down-band tracks, so it will require pre-reading and rewriting the modified sectors and all down-band sectors.  There's an interesting paper on this published by Carnegie Mellon's Parallel Data Laboratory that outlines some of the potentially significant performance implications and ways that they may be mitigated.

 

 

It might help with "apparent" performance, but using it has a big negative. Data is not protected by redundancy until it is copied to the protected array. I do not use cache drives for this reason. I'd rather lose performance. And you have to pay the piper overnight, and if the drives are as slow as you are predicting, might not be completed by the time the next day comes!

 

Agree -- I don't use a cache drive for the same reason.  However, with btrfs cache pools, my understanding is that the cache is also fault-tolerant.    Assuming that's a feature available in v6 final, that should let you mitigate the write speeds without losing fault tolerance for newly written data.

 

 

Read the specs, they are rated 150MB/sec average read/write and max 190MB/sec read, both exceed your typical unRAID 1gbe.

 

There are two different write performance considerations:  (a) Newly written data ... the drive's firmware keeps track of which tracks have been written and which have not (similar to how SSDs do for the NAND cells) ... which can be written at very good speeds (likely the 150MB/s noted in the specs); and (b) re-writes, which are impacted by what's been outlined already in terms of updating all down-band sectors.    Since these are marketed as "Archive HDDs" designed for write-once applications, I suspect the specs are for these initial writes.

 

We won't know the re-write performance until there are some independent tests documented, which I haven't seen.  What IS known is WHAT has to happen for a rewrite; and it's a simple physical fact that the mechanical operations involved are clearly going to take a notable amount of time.  There's no way that re-writes will come close to 150MB/s ... at least not sustainably [Clearly, as I've already noted, if there's room in the drive's buffer for a modest size write, that write will be "done" from the PC's perspective long before it's actually done on the drive.]

 

 

I think we are now saying the same thing. Sequential writes (what you call newly written data) will have good write performance while random writes to specific sectors will have the penalty. Mostly I expect unRaid users are doing sequential writes and that performance, even parity performance, will be ok. I expect that fragmentation will not be well tolerated with these drives as it could cause a fair amount of non-sequential activity. But as I've said, real-world experience will answer the question better than our suppositions. I think concerns of abysmal parity performance are premature.

Agree to an extent.  Sequential writes aren't necessarily "newly written data" ... but as a drive is initially filled they're effectively the same thing, since most (or at least a high percentage of) UnRAID users tend to fill drives with media and then the drive is effectively read-only.  But if the content is relatively dynamic, then even though you're writing sequential data, it's likely that the sectors you're writing them to have previously written data on them (even if it's been deleted by your file system ... a drive doesn't "know" what file system's on it or if the data on the sectors is currently active or not) => and thus the "read and rewrite' process will apply for the tracks in that band.

 

... an afterthought:  Note that if you pre-clear a drive, then every sector will have been written to, so from the drive's perspective there are NO unwritten sectors.    This means that there will indeed be read/rewrites on the shingled bands even if you're filling the drive with data for the first time.    The pre-clear will have the interesting side-effect of making the initial data fill of the drive slower 

 

While I agree we wont' really know the parity performance until some of these units are actually in service for this purpose; it's also very clear that the use case for parity will result in extensive band rewrites, since parity sectors are rewritten every time there's a write to ANY drive.  Unlike the data drives, the parity content is definitely not static, and any given sector is rewritten any time the corresponding sector on ANY drive is written to.    It's premature to say just how bad parity performance will be ... or whether "abysmal" will be an appropriate adjective ... but it's pretty clear that it won't be good for heavily used arrays.

 

 

 

A sequential write is writing a long series of consecutive sectors. Whether the sectors previously had data on them or not is not the drive's concern - only the file system knows or cares. Your notion that the first write matters seems false.

 

You have a preconceived notion that this is going to be a performance problem. You may be right, but I can argue both sides and think we need to wait and see. It matters less about the drive and its raw performance and more about the intelligence built into the firmware and maybe even OS drivers (if one is supplied specifically for these drives).

 

IF a person bought one for parity and had performance issues that cache wouldn't solve, the remedy is to use a RAID0 pair OR buy a large non-SMR drive for parity and move the SMR to a data slot.