OK, this looks bad. What do I do next?

[lionceau]

I'm no expert on the matter but surely it can't be a good idea to use SMR drives as parity?

 

They have two levels of cache (128MB DRAM + 20GB on-disk) managed by a firmware that's optimized for archival (few, large sequential writes). The screenshots suggest Parity workload is the exact opposite.

 

Any time a data disk is written to' date=' the parity disk needs to be updated as well. Each write to a parity-protected unRAID data disk results in 4 disk operations: a read and write for parity, and a read and write for data. The platter of each disk has to make a full revolution after reading to position the disk head back over the sector being written.[/quote']

 

That seems like a huge headache waiting to happen once the SMR drives have been populated with data that needs to be overwritten while the cache is full. My ST8000AS0002 dropped to <10 MB/s sequential write speed in those cases.

 

 

[Karyudo]

Which screenshots?

 

Right now, my parity is being rebuilt on SMR drives at 88 MB/s. Not the speediest, but not the "less than 10 MB/s" you were getting. Whether I wait 24 hours or just 12 hours (say) for the parity to be written doesn't really affect me.

 

Day-to-day, I've never noticed an issue with write speeds to SMR-based parity. Downloading (even at 150 Mbps) and unpacking seems to happen much more slowly than moving, so I guess I never fill up the cache on the drives?

 

I figure if I start to notice abysmal speeds "on the regular," I'll consider spending some more money and getting some non-SMR 8TB parity drives instead. But SMR drives are so much cheaper that I think I'll be willing to tolerate quite a lot of speed drop before that happens.

 

The aversion to SMR drives in all the forums I read to me feels a little, "sure it works in practice, but can you make it work in theory?" I can't disagree that on paper, using SMR drives for parity looks sub-optimal. But in practice, I've never noticed or been bothered by it.