Re: [gentoo-user] [OT] SMR drives (WAS: cryptsetup close and device in use when it is not)

[William Kenworthy]

On 30/7/21 10:29 pm, Rich Freeman wrote:
> On Fri, Jul 30, 2021 at 1:14 AM William Kenworthy <billk@×××××××××.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