On Fri, Jul 30, 2021 at 1:14 AM William Kenworthy <bi...@iinet.net.au> wrote: > > 2. btrfs scrub (a couple of days) >
Was this a read-only scrub, or did this involve repair (such as after losing a disk/etc)? My understanding of SMR is that it is supposed to perform identically to CMR for reads. If you've just recently done a bunch of writes I could see there being some slowdown due to garbage collection (the drive has a CMR cache which gets written out to the SMR regions), but other than that I'd think that reads would perform normally. Now, writes are a whole different matter and SMR is going to perform terribly unless it is a host-managed drive (which the consumer drives aren't), and the filesystem is SMR-aware. I'm not aware of anything FOSS but in theory a log-based filesystem should do just fine on host-managed SMR, or at least as well as it would do on CMR (log-based filesystems tend to get fragmented, which is a problem on non-SSDs unless the application isn't prone to fragmentation in the first place, such as for logs). Honestly I feel like the whole SMR thing is a missed opportunity, mainly because manufacturers decided to use it as a way to save a few bucks instead of as a new technology that can be embraced as long as you understand its benefits and limitations. One thing I don't get is why it is showing up on all sorts of smaller drives. I'd think the main application would be for large drives - maybe a drive that is 14TB as CMR could have been formatted as 20TB as SMR for the same price, and somebody could make that trade-off if it was worth it for the application. Using it on smaller drives where are more likely to be general-purpose is just going to cause issues for consumers who have no idea what they're getting into, particularly since the changes were sneaked into the product line. Somebody really needs to lose their job over this... -- Rich
