Western Digital recently announced new data center HDDs that increase Shingled Magnetic Recording (SMR) capacity to 32TB and Conventional Magnetic Recording (CMR) capacity to 26TB. The company...
Assuming that these have fairly impressive 100 MB/s sustained write speed, then it’s going to take about 93 hours to write the whole contents of the disk - basically four days. That’s a long time to replace a failed drive in a RAID array; you’d need to consider multiple disks of redundancy just in case another one fails while you’re resilvering the first.
I’m guessing that only works if the file is smaller than the RAM cache of the drives. Transfer a file that’s bigger than that, and it will go fast at first, but then fill the cache and the rate starts to drop closer to 100 MB/s.
My data hoarder drives are a pair of WD ultrastar 18TB SAS drives on RAID1, and that’s how they tend to behave.
This is for very long sustained writes, like 40TiB at a time. I can’t say I’ve ever noticed any slowdown, but I’ll keep a closer eye on it next time I do another huge copy. I’ve also never seen any kind of noticeable slowdown on my 4 8TB SATA WD golds, although they only get to about 150MB/s each.
EDIT: The effect would be obvious pretty fast at even moderate write speeds, I’ve never seen a drive with more than a GB of cache. My 16TB drives have 256MB, and the 8TB drives only 64MB of cache.
This is one of the reasons I use unRAID with two parity disks. If one fails, I’ll still have access to my data while I rebuild the data on the replacement drive.
Although, parity checks with these would take forever, of course…
That’s a pretty common failure scenario in SANs. If you buy a bunch of drives, they’re almost guaranteed to come from the same batch, meaning they’re likely to fail around the same time. The extra load of a rebuild can kill drives that are already close to failure.
Which is why SANs have hot spares that can be allocated instantly on failure. And you should use a RAID level with enough redundancy to meet your reliability needs. And RAID is not backup, you should have backups too.
Also why you need to schedule periodical parity scrubs, then the “extra load of a rebuild” is exercised regularly so weak drives will be found long before a rebuild is needed.
It’s more likely if you bought all the drives from the same store (since that increases the likelihood that they’re from the same batch), so you should make sure that you buy them from different stores.
Assuming that these have fairly impressive 100 MB/s sustained write speed, then it’s going to take about 93 hours to write the whole contents of the disk - basically four days. That’s a long time to replace a failed drive in a RAID array; you’d need to consider multiple disks of redundancy just in case another one fails while you’re resilvering the first.
My 16TB ultrastars get upwards of 180MB/s sustained read and write, these will presumably be faster than that as the density is higher.
I’m guessing that only works if the file is smaller than the RAM cache of the drives. Transfer a file that’s bigger than that, and it will go fast at first, but then fill the cache and the rate starts to drop closer to 100 MB/s.
My data hoarder drives are a pair of WD ultrastar 18TB SAS drives on RAID1, and that’s how they tend to behave.
This is for very long sustained writes, like 40TiB at a time. I can’t say I’ve ever noticed any slowdown, but I’ll keep a closer eye on it next time I do another huge copy. I’ve also never seen any kind of noticeable slowdown on my 4 8TB SATA WD golds, although they only get to about 150MB/s each.
EDIT: The effect would be obvious pretty fast at even moderate write speeds, I’ve never seen a drive with more than a GB of cache. My 16TB drives have 256MB, and the 8TB drives only 64MB of cache.
This is one of the reasons I use unRAID with two parity disks. If one fails, I’ll still have access to my data while I rebuild the data on the replacement drive.
Although, parity checks with these would take forever, of course…
That’s a pretty common failure scenario in SANs. If you buy a bunch of drives, they’re almost guaranteed to come from the same batch, meaning they’re likely to fail around the same time. The extra load of a rebuild can kill drives that are already close to failure.
Which is why SANs have hot spares that can be allocated instantly on failure. And you should use a RAID level with enough redundancy to meet your reliability needs. And RAID is not backup, you should have backups too.
Also why you need to schedule periodical parity scrubs, then the “extra load of a rebuild” is exercised regularly so weak drives will be found long before a rebuild is needed.
2 parity is standard and should still be adequate. Likelihood of two failures within four days on the same array is small.
It’s more likely if you bought all the drives from the same store (since that increases the likelihood that they’re from the same batch), so you should make sure that you buy them from different stores.
Except these drives are SMR - not something you’d want in a RAID.
Title literally says SMR for one size and CMR for another. Not that I should expect much from a .ml account.