On 31/7/21 11:14 am, William Kenworthy wrote: > On 30/7/21 10:29 pm, Rich Freeman wrote: >> 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... >> > 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 > > > > Still almost same scrub speed and 22.5 hours after running for nearly 2 1/2 hours.
rattus ~ # btrfs scrub status /run/media/wdk/cae17311-19ca-4e3c-b476-304e02c50694 UUID: cae17311-19ca-4e3c-b476-304e02c50694 Scrub started: Sat Jul 31 10:52:07 2021 Status: running Duration: 2:22:44 Time left: 20:04:49 ETA: Sun Aug 1 09:19:43 2021 Total to scrub: 3.23TiB Bytes scrubbed: 350.41GiB (10.59%) Rate: 41.90MiB/s Error summary: no errors found rattus ~ # Cancelled and restarted it as a normal scrub - same speed/timings - I think if errors are found, thats when it would slow down. rattus ~ # btrfs scrub status /run/media/wdk/cae17311-19ca-4e3c-b476-304e02c50694 UUID: cae17311-19ca-4e3c-b476-304e02c50694 Scrub started: Sat Jul 31 13:18:51 2021 Status: running Duration: 0:00:05 Time left: 22:27:47 ETA: Sun Aug 1 11:46:43 2021 Total to scrub: 3.23TiB Bytes scrubbed: 209.45MiB (0.01%) Rate: 41.89MiB/s Error summary: no errors found rattus ~ # BillK
