From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 2B6351381F3 for ; Sat, 31 Jul 2021 03:15:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C4F3CE08A0; Sat, 31 Jul 2021 03:15:22 +0000 (UTC) Received: from icp-osb-irony-out6.external.iinet.net.au (icp-osb-irony-out6.external.iinet.net.au [203.59.1.106]) by pigeon.gentoo.org (Postfix) with ESMTP id D2D71E087E for ; Sat, 31 Jul 2021 03:15:17 +0000 (UTC) X-SMTP-MATCH: 0 IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AW8O/DKqjVZqZvaTMlchgmy4aV5rZeYIsim?= =?us-ascii?q?QD101hICG9Ffbo6fxG/c5rqiMc7Qx7ZJhOo7y90dm7K080maQa3WBpB8bEYO?= =?us-ascii?q?CEghrVEGgB1/qA/9SIIUSXm9K1s50AT0EUMr3N5DZB4vrS0U2TFso73dWdmZ?= =?us-ascii?q?rY/ts3xB9WPHxXQpAlwD5YJ2+gYzdLbTgDJJYwGZaGouBmilObCAwqh7yAdx?= =?us-ascii?q?w4tweqnayuqHopCSR2YSLOKGG1/EqVAcXBYnql4is=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DfBQCQvwRh/+hY69xaHQEBAQEJARI?= =?us-ascii?q?BBQUBQAmBPwUBCwEBgXSCAgEBAWmER4kEhxEBAQEBAQEGgRQtAzgBV4Mxhii?= =?us-ascii?q?GTowmCwEBAQEBAQEBAQlBBAEBhFgCgwAmNwYOAQIEFQEBAQUBAQEBAQYDAYE?= =?us-ascii?q?khXVAARABBAGFbAEFIw8BIxkaCQIYAgImAgJXEwYCAQGCbYJiJY9cnAqBMYE?= =?us-ascii?q?BhGiFIoEQKgGNbkN9gRCBFScPgW5KNz6DfjCDLYJkBIMaeg4tJiwlUoEDkVJ?= =?us-ascii?q?IjgydFYMxnjMGDwUmg2ORawgvkGKGd7RTgT44gX5NHxmDJFAZDlYBjVEDFhW?= =?us-ascii?q?OJTQBAQEvOAIGAQoBAQMJhhCBEmiCRgEB?= X-IPAS-Result: =?us-ascii?q?A2DfBQCQvwRh/+hY69xaHQEBAQEJARIBBQUBQAmBPwUBC?= =?us-ascii?q?wEBgXSCAgEBAWmER4kEhxEBAQEBAQEGgRQtAzgBV4MxhiiGTowmCwEBAQEBA?= =?us-ascii?q?QEBAQlBBAEBhFgCgwAmNwYOAQIEFQEBAQUBAQEBAQYDAYEkhXVAARABBAGFb?= =?us-ascii?q?AEFIw8BIxkaCQIYAgImAgJXEwYCAQGCbYJiJY9cnAqBMYEBhGiFIoEQKgGNb?= =?us-ascii?q?kN9gRCBFScPgW5KNz6DfjCDLYJkBIMaeg4tJiwlUoEDkVJIjgydFYMxnjMGD?= =?us-ascii?q?wUmg2ORawgvkGKGd7RTgT44gX5NHxmDJFAZDlYBjVEDFhWOJTQBAQEvOAIGA?= =?us-ascii?q?QoBAQMJhhCBEmiCRgEB?= X-IronPort-AV: E=Sophos;i="5.84,283,1620662400"; d="scan'208";a="321409961" Received: from 220-235-88-232.dyn.iinet.net.au (HELO mail.infra.localdomain) ([220.235.88.232]) by icp-osb-irony-out6.iinet.net.au with ESMTP; 31 Jul 2021 11:15:13 +0800 Received: from localhost (mail.infra.localdomain [127.0.0.1]) by mail.infra.localdomain (Postfix) with ESMTP id 0B70C418 for ; Sat, 31 Jul 2021 11:15:13 +0800 (AWST) X-Virus-Scanned: amavisd-new at localdomain Received: from mail.infra.localdomain ([127.0.0.1]) by localhost (mail.infra.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvYK-wvBxg6u for ; Sat, 31 Jul 2021 11:14:23 +0800 (AWST) Subject: Re: [gentoo-user] [OT] SMR drives (WAS: cryptsetup close and device in use when it is not) To: gentoo-user@lists.gentoo.org References: <9946c2eb-bb5c-a9c0-ced9-1ac269cd69a0@gmail.com> <6ecbf2d6-2c6f-3f66-5eee-f4766d5e5254@gmail.com> <24805.48814.331408.860941@tux.local> <5483630c-3cd1-bca2-0a6d-62bb85a5adc6@gmail.com> <96fc901a-2ce4-0ea0-0ed1-1c529145c0e9@gmail.com> <6102DB58.7040103@youngman.org.uk> <56d64f52-1b9a-1309-c720-06bb63c9f80a@iinet.net.au> From: William Kenworthy Message-ID: <7a8c52c3-4c96-89ac-ace0-6eb4b8f1401f@iinet.net.au> Date: Sat, 31 Jul 2021 11:14:23 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-AU X-Archives-Salt: dd4641a2-7711-4c5c-8c1f-a06381e864f6 X-Archives-Hash: 57a81b2687959ab1a51658f9f0d7581f On 30/7/21 10:29 pm, Rich Freeman wrote: > On Fri, Jul 30, 2021 at 1:14 AM William Kenworthy 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