3 ms·

Open question: Speaking as someone who accidentally bought SMR drives from Seagate that weren't advertised as such, what's the primary danger of using these dr

Open question: Speaking as someone who accidentally bought SMR drives from Seagate that weren't advertised as such, what's the primary danger of using these drives in a _new_ ZFS setup? From what I've seen, the write speed is bad enough that rebuilds might be problematic in ZFS. But since I'm not doing a rebuild, and since I can swap out the drive for a non-SMR alternative whenever one fails and I do need to do a rebuild, are they still relatively safe to use?

magicalhippo 6y ago
Depends on workload of course, but my buddy has used 8x Seagate Archive drives (which were the first SMRs) in a ZFS-based media/file server for years without issue. If any new disk you replace it with is non-SMR, then you shoud be good as far as I can see.
seabrookmx 6y ago
My anecdotal evidence, based on a fairly small (16TB) pool for personal use such as backups and media, is that the _Seagate_ SMR drives are fine. I've done multiple resilvers and they're definitely slower than conventional drives at that task, but the main issue people are seeing with WD drives is that in certain cases the drives take multiple seconds to respond to an ATA command, making the system think the drive is defective. The Seagate drives don't seem to suffer from this problem. There's lots of documentation out there on people using Seagate "Archive" drives in NAS's as well.. these were some of the earliest SMR drives and were on the market before the tech became more mainstream. Their results seem to align with what I'm seeing even though mine are branded "Barracuda Compute." So while I wouldn't be using _any_ SMR drives for a production workload, I'm perfectly happy with the 8TB Seagate SMR drives I picked up for $185 CAD each for my home use.
- 65a 6y ago
  I ran a large array of 5TB Seagate SMR drives. Everything was fine until a disk failed, at which point the resilver took almost 24h. This was an uncomfortable window, but otherwise the array was fine, although write speeds were about 15-40MB/s in many cases.
  - seabrookmx 6y ago
    Yup. That window is exactly why I wouldn't want to run a setup like that in a production setting. But based on the reports of the WD drives, they are likely to never successfully resilver. Which is obviously much worse.
Maakuth 6y ago
My understanding is that the major issue with these WD drives is that they try to hide the fact that they are SMR. For desktop workload or similar, it's relatively okay, because there's some part of the disk that's CMR (the traditional HDD encoding) and the disk firmware migrated data from there to SMR in the background. As long as writes to the disk accumulate in a way that leaves time for the firmware to run this migration, the writes appear to work similarly to full CMR disks. This is called 'disk managed SMR'. The other, I'd say the correct, way to do this is to have the disk report its SMRness to the operating system. That lets the OS issue TRIM commands to the disk for areas that are not used to store data, which makes the writes quicker, SMR's performance having to do with the fact that it needs to be written in way larger blocks than CMR. For ZFS or RAID rebuilds on drive-managed SMR drives, the CMR area will be filled quickly, as the whole disk is written at once. This means the rebuild will be very slow, and if I got it right, some firmware versions even stop accepting writes when the CMR area is full. So the rebuild situation is where the problems arise - already existing arrays should be fine, especially with SMR disks that do let the OS know about them being SMR.

magicalhippo 6y ago

Depends on workload of course, but my buddy has used 8x Seagate Archive drives (which were the first SMRs) in a ZFS-based media/file server for years without issue. If any new disk you replace it with is non-SMR, then you shoud be good as far as I can see.

seabrookmx 6y ago

My anecdotal evidence, based on a fairly small (16TB) pool for personal use such as backups and media, is that the _Seagate_ SMR drives are fine. I've done multiple resilvers and they're definitely slower than conventional drives at that task, but the main issue people are seeing with WD drives is that in certain cases the drives take multiple seconds to respond to an ATA command, making the system think the drive is defective. The Seagate drives don't seem to suffer from this problem. There's lots of documentation out there on people using Seagate "Archive" drives in NAS's as well.. these were some of the earliest SMR drives and were on the market before the tech became more mainstream. Their results seem to align with what I'm seeing even though mine are branded "Barracuda Compute." So while I wouldn't be using _any_ SMR drives for a production workload, I'm perfectly happy with the 8TB Seagate SMR drives I picked up for $185 CAD each for my home use.

65a 6y ago
I ran a large array of 5TB Seagate SMR drives. Everything was fine until a disk failed, at which point the resilver took almost 24h. This was an uncomfortable window, but otherwise the array was fine, although write speeds were about 15-40MB/s in many cases.
- seabrookmx 6y ago
  Yup. That window is exactly why I wouldn't want to run a setup like that in a production setting. But based on the reports of the WD drives, they are likely to never successfully resilver. Which is obviously much worse.

Maakuth 6y ago

My understanding is that the major issue with these WD drives is that they try to hide the fact that they are SMR. For desktop workload or similar, it's relatively okay, because there's some part of the disk that's CMR (the traditional HDD encoding) and the disk firmware migrated data from there to SMR in the background. As long as writes to the disk accumulate in a way that leaves time for the firmware to run this migration, the writes appear to work similarly to full CMR disks. This is called 'disk managed SMR'. The other, I'd say the correct, way to do this is to have the disk report its SMRness to the operating system. That lets the OS issue TRIM commands to the disk for areas that are not used to store data, which makes the writes quicker, SMR's performance having to do with the fact that it needs to be written in way larger blocks than CMR. For ZFS or RAID rebuilds on drive-managed SMR drives, the CMR area will be filled quickly, as the whole disk is written at once. This means the rebuild will be very slow, and if I got it right, some firmware versions even stop accepting writes when the CMR area is full. So the rebuild situation is where the problems arise - already existing arrays should be fine, especially with SMR disks that do let the OS know about them being SMR.