4 ms·

As benchmarked in the article, SMR drives rebuild Linux RAID fine because it's just a sequential data overwrite. The problem occurs when you are dealing with s

by dannyw 6y ago

As benchmarked in the article, SMR drives rebuild Linux RAID fine because it's just a sequential data overwrite. The problem occurs when you are dealing with sequential files with small sector sizes, and non-sequential files, where performance is abysmal: 93% slower than CMR as benchmarked by servethehome and Ars.

zozbot234 6y ago
The problem is not just the slow performance, but the fact that these drives can be dropped from the array when rebuilding - RAID implementations including the one in ZFS treat abysmal performance as damage and route around it. The performance problem could be addressed simply by raising the number of drives in the array (RAID5 to RAID6 or more).
- ezoe 6y ago
  Isn't that a problem of ZFS? I don't mind SMR HDD if it was labeled as such and warn about it's weird performance traits.
  - ubercow13 6y ago
    This whole issue was originally that Western Digital was trying to hide which HDDs were SMR. ZFS can't be changed to have special behaviour for SMR drives if the vendors try to hide the fact they are SMR, even from software. It wouldn't be able to identify them.
    - ezoe 6y ago
      Well, that's bad.
fomine3 6y ago
Rebuilding ZFS array is normally faster than traditional array because it won't sync whole disk but sync only used blocks. This PR looks like adding support for traditional sequential rebuild way like Linux MD that suitable for SMR disks. https://github.com/openzfs/zfs/pull/10349 https://github.com/openzfs/zfs/pull/10349
StillBored 6y ago
Their test is completely invalid, they only used a small portion of the disk in a sequential manner. Likely the "cache" portion of the array is a significant portion of the partition they created. Further, I'm not aware of a single raid system built in the last 20 years that doesn't do online rebuild. This means its only sequential IO as long as the RAID controller isn't servicing other IO requests. Futher it also assumes that your running a dead simple RAID system that is RAIDing the entire array rather than doing the RAID on top of a LVM/thin provisioning like setup (this is basically ZFS's problem). Frankly, I would be willing to bet that its possible to tweak a benchmark like iometer to use a sufficiently large part of the disk with a 50% random RW workload and cause quite a number of RAID controllers to kick the drives for write timeouts. Some percentage of them might even kick multiple disks at the same time resulting in complete array loss.

by dannyw 6y ago

zozbot234 6y ago

The problem is not just the slow performance, but the fact that these drives can be dropped from the array when rebuilding - RAID implementations including the one in ZFS treat abysmal performance as damage and route around it. The performance problem could be addressed simply by raising the number of drives in the array (RAID5 to RAID6 or more).

ezoe 6y ago
Isn't that a problem of ZFS? I don't mind SMR HDD if it was labeled as such and warn about it's weird performance traits.
- ubercow13 6y ago
  This whole issue was originally that Western Digital was trying to hide which HDDs were SMR. ZFS can't be changed to have special behaviour for SMR drives if the vendors try to hide the fact they are SMR, even from software. It wouldn't be able to identify them.
  - ezoe 6y ago
    Well, that's bad.

fomine3 6y ago

Rebuilding ZFS array is normally faster than traditional array because it won't sync whole disk but sync only used blocks. This PR looks like adding support for traditional sequential rebuild way like Linux MD that suitable for SMR disks. https://github.com/openzfs/zfs/pull/10349 https://github.com/openzfs/zfs/pull/10349

StillBored 6y ago

Their test is completely invalid, they only used a small portion of the disk in a sequential manner. Likely the "cache" portion of the array is a significant portion of the partition they created. Further, I'm not aware of a single raid system built in the last 20 years that doesn't do online rebuild. This means its only sequential IO as long as the RAID controller isn't servicing other IO requests. Futher it also assumes that your running a dead simple RAID system that is RAIDing the entire array rather than doing the RAID on top of a LVM/thin provisioning like setup (this is basically ZFS's problem). Frankly, I would be willing to bet that its possible to tweak a benchmark like iometer to use a sufficiently large part of the disk with a 50% random RW workload and cause quite a number of RAID controllers to kick the drives for write timeouts. Some percentage of them might even kick multiple disks at the same time resulting in complete array loss.