From: William Kenworthy <billk@iinet.net.au>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] [OT] SMR drives (WAS: cryptsetup close and device in use when it is not)
Date: Sat, 31 Jul 2021 13:23:51 +0800 [thread overview]
Message-ID: <b92f585f-6a4e-c602-33f2-9d7a3e9a72ae@iinet.net.au> (raw)
In-Reply-To: <7a8c52c3-4c96-89ac-ace0-6eb4b8f1401f@iinet.net.au>
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 <billk@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
next prev parent reply other threads:[~2021-07-31 5:24 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-14 4:50 [gentoo-user] cryptsetup close and device in use when it is not Dale
2021-06-15 13:48 ` Ramon Fischer
2021-06-15 14:21 ` Dale
2021-06-15 14:52 ` Jack
2021-06-15 15:26 ` Dale
2021-06-15 19:04 ` Ramon Fischer
2021-06-21 4:18 ` Dale
2021-06-21 4:49 ` Dale
2021-06-21 5:41 ` Dale
2021-06-21 5:59 ` Dale
2021-06-28 3:35 ` Dale
2021-07-05 3:19 ` Dale
2021-07-06 18:40 ` Ramon Fischer
2021-07-06 19:43 ` Dale
2021-07-07 14:48 ` Dr Rainer Woitok
2021-07-07 18:08 ` Dale
2021-07-08 8:20 ` Ramon Fischer
2021-07-12 8:31 ` Dale
2021-07-12 13:14 ` Ramon Fischer
2021-08-02 13:33 ` Dale
2021-08-09 13:38 ` Ramon Fischer
2021-09-19 11:55 ` Dale
2021-07-25 20:29 ` Frank Steinmetzger
2021-07-25 23:10 ` Dale
2021-07-26 21:00 ` Frank Steinmetzger
2021-07-26 22:48 ` Dale
2021-07-29 16:46 ` Wols Lists
2021-07-29 20:55 ` [gentoo-user] [OT] SMR drives (WAS: cryptsetup close and device in use when it is not) Frank Steinmetzger
2021-07-29 21:31 ` Frank Steinmetzger
2021-07-30 12:48 ` Frank Steinmetzger
2021-07-30 5:14 ` William Kenworthy
2021-07-30 14:29 ` Rich Freeman
2021-07-30 16:50 ` antlists
2021-07-30 18:38 ` Rich Freeman
2021-07-31 3:14 ` William Kenworthy
2021-07-31 3:50 ` Wols Lists
2021-07-31 4:58 ` William Kenworthy
2021-07-31 12:12 ` Rich Freeman
2021-08-01 0:41 ` Frank Steinmetzger
2021-08-01 0:56 ` Rich Freeman
2021-07-31 16:38 ` antlists
2021-08-01 0:50 ` Frank Steinmetzger
2021-08-01 3:36 ` William Kenworthy
2021-08-01 3:46 ` William Kenworthy
2021-08-01 21:38 ` Frank Steinmetzger
2021-08-02 5:38 ` William Kenworthy
2021-08-02 21:52 ` Frank Steinmetzger
2021-08-02 23:10 ` William Kenworthy
2021-08-03 8:18 ` Frank Steinmetzger
2021-08-05 20:40 ` Frank Steinmetzger
2021-08-06 7:22 ` William Kenworthy
2021-08-01 21:55 ` Frank Steinmetzger
2021-08-02 6:12 ` William Kenworthy
2021-08-02 22:03 ` Frank Steinmetzger
2021-08-02 23:35 ` William Kenworthy
2021-08-01 3:41 ` William Kenworthy
2021-08-01 21:41 ` Frank Steinmetzger
2021-07-31 12:21 ` Rich Freeman
2021-07-31 12:59 ` William Kenworthy
2021-07-31 13:30 ` Rich Freeman
2021-08-01 3:05 ` William Kenworthy
2021-08-01 11:37 ` Rich Freeman
2021-07-31 5:23 ` William Kenworthy [this message]
2021-06-15 17:48 ` [gentoo-user] Re: cryptsetup close and device in use when it is not Remy Blank
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b92f585f-6a4e-c602-33f2-9d7a3e9a72ae@iinet.net.au \
--to=billk@iinet.net.au \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox