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 0A61A1382C5 for ; Tue, 23 Jun 2020 17:20:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AB76BE089E; Tue, 23 Jun 2020 17:20:35 +0000 (UTC) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (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 610D0E0897 for ; Tue, 23 Jun 2020 17:20:35 +0000 (UTC) Received: by mail-ej1-f50.google.com with SMTP id dp18so22422445ejc.8 for ; Tue, 23 Jun 2020 10:20:35 -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=t7uYsZ8E/FzUnYJmT+4AQ4m6sI20mDSlRWeBKXB0Yog=; b=Bjt84nBxwld5CFSDt8KhktOLwreshw9mZdGO/SsT8hdfdhqJ/H7071CExV4zKFmsz7 BxdnP/n/oVT80ICS3I3q2Q86/Lbul/J2xO1KXcqFMcPpGvx1hlM9LEsm7FRRCRaPeY0r Y82j79smFC+Cs/H1XA3A/+CvHfX+fAtNb+B6DNHG/GPSa5OLF07L4wgUnlGwEb07c4Hh R3MQh8jUDUsWaIF8v83fetAddfZcQ0JcU8gmT6703UE7r51M0z5to+JY3EJB0isXiaoR AMl8G0hr4VxWY+1+Pxl1Bc77V9eV7IZ8MOefsxMqz7pOfdo5gdzVv5ScLG2BHHt3P6js CQuw== X-Gm-Message-State: AOAM532Jo7Ta0Q3IiDUq+X2KQXYH3wei59PrSLTHtukZBnXSECCf1/fF UvtpSzsH6Qx079qFnDOsgf0GqQ99im0iUXInrq9Cw4tD X-Google-Smtp-Source: ABdhPJwCJL+O9ZAMW9yWCqI8WdqlJT1r9WdEBCQUiN4rtj5kENy+dekBd3fUkpqnBXr/52FjQoaKsT6IOEK399ldCZ0= X-Received: by 2002:a17:906:538e:: with SMTP id g14mr7928848ejo.300.1592932833579; Tue, 23 Jun 2020 10:20:33 -0700 (PDT) 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 References: <6d77acb3-5754-06cb-b8ef-2f1a5d7d8084@gmail.com> <5EE8A6C9.9020900@youngman.org.uk> <5611481.lOV4Wx5bFT@lenovo.localdomain> <4f35306e-e509-4cae-907d-7eb026c008e9@www.fastmail.com> In-Reply-To: <4f35306e-e509-4cae-907d-7eb026c008e9@www.fastmail.com> From: Rich Freeman Date: Tue, 23 Jun 2020 13:20:21 -0400 Message-ID: Subject: Re: [gentoo-user] Testing a used hard drive to make SURE it is good. To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: b25abb5f-6d49-494b-abc6-b3d5ac770fa7 X-Archives-Hash: 940581999defeb52a09ac79f2b7b7f7a On Tue, Jun 23, 2020 at 12:14 PM Sid Spry wrote: > > So if I'm understanding properly most drive firmware won't let you > operate the device in an append-only mode? So, there are several types of SMR drives. There are host-managed, drive-managed, and then hybrid devices that default to drive-managed for compatibility reasons but the host can send them a command to take full control so that it is the same as host-managed. A host-managed drive just does what the host tells it to. If the host tells it to do a write that obliterates some other data on the disk, the drive just does it, and it is the job of the host OS/filesystem/application to make sure that they protect any data they care about. At the drive level these perform identically to CMR because they just seek and write like any other drive. At the application level these could perform differently since the application might end up having to work around the drive. However, these drives are generally chosen for applications where this is not a big problem or where the problems can be efficiently mitigated. A drive-managed drive just looks like a regular drive to the host, and it ends up having to do a lot of read-before-rewrite operations because the host is treating it like it is CMR but the drive has to guarantee that nothing gets lost. A drive-managed disk has no way to operate in "append-only" mode. I'm not an expert in ATA but I believe disks are just given an LBA and a set of data to write. Without support for TRIM the drive has no way to know if it is safe to overwrite nearby cylinders, which means it has to preserve them. The biggest problem is that the vendors were trying to conceal the nature of the drives. If they advertised TRIM support it would be pretty obvious they were SMR. > If any do I suspect > NILFS (https://en.wikipedia.org/wiki/NILFS) may be a good choice: > > "NILFS is a log-structured filesystem, in that the storage medium is treated > like a circular buffer and new blocks are always written to the end. [...]" > On a host-managed disk this would perform the same as on a CMR disk, with the possible exception of any fixed metadata (I haven't read the gory details on the filesystem). If it has no fixed metadata (without surrounding unused tracks) then it would have no issues at all on SMR. F2FS takes a similar approach for SSDs, though it didn't really take off because ext4's support is good enough and I suspect that modern SSDs are fast enough at erasing. As I mentioned SSDs have the same issue as SMR, just the scale of the problem is much smaller. The erase blocks are much smaller so less data needs to be read/rewritten following an erase, and then the operations are all just vastly faster. Taking 3x longer on a 1us operation is far different from taking 100x longer on a 100ms operation. -- Rich