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 3654C1382C5 for ; Tue, 16 Jun 2020 23:38:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 21259E09D4; Tue, 16 Jun 2020 23:38:25 +0000 (UTC) Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) (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 6362FE09CD for ; Tue, 16 Jun 2020 23:38:24 +0000 (UTC) Received: from host86-173-103-225.range86-173.btcentralplus.com ([86.173.103.225] helo=[192.168.1.65]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1jlL9p-000CQU-6F for gentoo-user@lists.gentoo.org; Wed, 17 Jun 2020 00:38:22 +0100 Subject: Re: [gentoo-user] Testing a used hard drive to make SURE it is good. To: gentoo-user@lists.gentoo.org References: <6d77acb3-5754-06cb-b8ef-2f1a5d7d8084@gmail.com> <5EE8A6C9.9020900@youngman.org.uk> <5611481.lOV4Wx5bFT@lenovo.localdomain> From: antlists Message-ID: <2fe8d752-b3f9-3187-a9fc-5c95c8030a10@youngman.org.uk> Date: Wed, 17 Jun 2020 00:38:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.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; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Archives-Salt: 25e7253c-6108-4c75-ad27-25badb7c1839 X-Archives-Hash: 96a4e924909eccc732273e8c9776c16f On 16/06/2020 13:25, Rich Freeman wrote: > And of course the problem with these latest hidden SMR drives is that > they generally don't support TRIM, This, I believe, is a problem with the ATA spec. I don't understand what's going on, but something like for these drives you need v4 of the spec, and only v3 is finalised. Various people have pointed out holes in this theory, so you don't need to add to them :-) But yes, I do understand that apparently there is no official standard way to send a trim to these drives ... > so even repeated sequential writes > can be a problem because the drive doesn't realize that after you send > block 1 you're going to send blocks 2-100k all sequentially. If it > knew that then it would just start overwriting in place obliterating > later tracks, since they're just going to be written next anyway. No it can't do that. Because when it overwrites the end of the file it will be obliterating other random files that aren't going to be overwritten ... > Instead this drive is going to cache every write until it can > consolidate them, which isn't terrible but it still turns every seek > into three (write buffer, read buffer, write permanent - plus updating > metadata). Which IS terrible if you don't give the drive down-time to flush the buffer ... > If they weren't being sneaky they could have made it > drive-managed WITH TRIM so that it worked more like an SSD where you > get the best performance if the OS uses TRIM, but it can fall back if > you don't. Sequential writes on trimmed areas for SMR should perform > identically to writes on CMR drives. You're forgetting one thing - rewriting a block on SSD or CMR doesn't obliterate neighbouring blocks ... with SMR for every track you rewrite you have to salvage the neighbouring track too ... Cheers, Wol