On 30/7/21 10:29 pm, Rich Freeman wrote: > On Fri, Jul 30, 2021 at 1:14 AM William Kenworthy <[email protected]> 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... > No, it was a normal scrub (read only is an option) - I did the scrub hoping it wasn't necessary but aware that crash halting the OS while doing a backup while the system was generating ooops after an upgrade wasn't going to guarantee a clean shutdown. Ive just kicked off a scrub -r and am getting 41Mb/s speed via the status check (its a usb3 on the disk side, and usb2 on the PC - configuration: driver=usb-storage maxpower=30mA speed=480Mbit/s). I will monitor for a couple of hours and see what happens then swap to a standard scrub and compare the read rate.
rattus ~ # date && btrfs scrub status /run/media/wdk/cae17311-19ca-4e3c-b476-304e02c50694 Sat 31 Jul 2021 10:55:43 AWST UUID: cae17311-19ca-4e3c-b476-304e02c50694 Scrub started: Sat Jul 31 10:52:07 2021 Status: running Duration: 0:03:35 Time left: 22:30:40 ETA: Sun Aug 1 09:26:23 2021 Total to scrub: 3.23TiB Bytes scrubbed: 8.75GiB (0.26%) Rate: 41.69MiB/s Error summary: no errors found lsusb: Bus 003 Device 007: ID 0bc2:331a Seagate RSS LLC Desktop HDD 5TB (ST5000DM000) (seagate lists it as a 5Tb drive managed SMR) It was sold as a USB3 4Tb desktop expansion drive, fdisk -l shows "Disk /dev/sde: 3.64 TiB, 4000787029504 bytes, 7814037167 sectors" and Seagate is calling it 5Tb - marketing! BillK
