From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-196556-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id C4012139000
for <garchives@archives.gentoo.org>; Fri, 30 Jul 2021 14:30:15 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id A8F40E0933;
Fri, 30 Jul 2021 14:30:08 +0000 (UTC)
Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id CB619E0918
for <gentoo-user@lists.gentoo.org>; Fri, 30 Jul 2021 14:30:07 +0000 (UTC)
Received: by mail-oi1-f170.google.com with SMTP id a19so13440102oiw.6
for <gentoo-user@lists.gentoo.org>; Fri, 30 Jul 2021 07:30:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=g8156Mz5KVLSt5AOUiARAzRmJ9fqzF/tputQpmz9gwo=;
b=h/KRp6SgF+2o++xrQvLKnf6bBnVCl361vcwM7tP0YWsTVy6+ng7rMJqFsUs0u7zV/P
PZ0ARQhpczrnmn3DF38+KadmQw7NmPrk1GMdXyufmTkFW3s4EYDl9QYJsEeqB8X0YjX/
mKgudztZPtpLps0lNtomJBS7Fm49MNfmrnmc1Izb4Np0FG0iGzidpVueLEUpG2rUXF/Z
wmjx/Izd9az7jGUdr1xrHTevKZHXLJGI7oD3FvsUGfgc0NxyYurOMj26XO17O0uySUxq
6h5or3LLG7TZdrY7A0zwrDayjv83pPfsTv8P+Q/79AOcHivuu5l5gaREFHQgz2QggMVK
RGhA==
X-Gm-Message-State: AOAM5317SFuR0+t3mSLIc/bQtm6PB3b2+Fogg2t6+RIcwefAMAx6sbjJ
wyhbzx4f/9Lgnne5aUxfL0MPzq9h9C3Hu6pdBsOvu+SG
X-Google-Smtp-Source: ABdhPJxtPjWj9qqgDpAOTqmyz9aYMJ4MS2LTJsGAFfzmgees+66fbHQ5nnauWEIbpXctDKv2t289eiORopjHooX5HP4=
X-Received: by 2002:a05:6808:218f:: with SMTP id be15mr2026463oib.75.1627655406652;
Fri, 30 Jul 2021 07:30:06 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
References: <9946c2eb-bb5c-a9c0-ced9-1ac269cd69a0@gmail.com>
<6ecbf2d6-2c6f-3f66-5eee-f4766d5e5254@gmail.com> <f48bc72e-dfea-fb10-28a9-89fee3195d29@gmail.com>
<AM6PR10MB24406ED1F1B405DFD39C0AD1EF1B9@AM6PR10MB2440.EURPRD10.PROD.OUTLOOK.COM>
<24805.48814.331408.860941@tux.local> <5483630c-3cd1-bca2-0a6d-62bb85a5adc6@gmail.com>
<YP3JvifkTInJsxl2@kern> <96fc901a-2ce4-0ea0-0ed1-1c529145c0e9@gmail.com>
<YP8igfk3Bt+al/vL@kern> <6102DB58.7040103@youngman.org.uk>
<YQMVtr83vkfzS0nP@kern> <56d64f52-1b9a-1309-c720-06bb63c9f80a@iinet.net.au>
In-Reply-To: <56d64f52-1b9a-1309-c720-06bb63c9f80a@iinet.net.au>
From: Rich Freeman <rich0@gentoo.org>
Date: Fri, 30 Jul 2021 10:29:54 -0400
Message-ID: <CAGfcS_=8sjEe60KEuVsoqEyj5TbK177H0vf2fY3yQp370h+VFw@mail.gmail.com>
Subject: Re: [gentoo-user] [OT] SMR drives (WAS: cryptsetup close and device
in use when it is not)
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset="UTF-8"
X-Archives-Salt: a571a2ab-b21e-4745-8054-2f6c2ed649e7
X-Archives-Hash: e34eebb64834faba6507645c4dfd5f6e
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...
--
Rich