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 11:14:23 +0800 [thread overview]
Message-ID: <7a8c52c3-4c96-89ac-ace0-6eb4b8f1401f@iinet.net.au> (raw)
In-Reply-To: <CAGfcS_=8sjEe60KEuVsoqEyj5TbK177H0vf2fY3yQp370h+VFw@mail.gmail.com>
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
next prev parent reply other threads:[~2021-07-31 3:15 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 [this message]
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
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=7a8c52c3-4c96-89ac-ace0-6eb4b8f1401f@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