From owner-freebsd-questions@freebsd.org Mon Aug 31 17:29:47 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75D499C67F2 for ; Mon, 31 Aug 2015 17:29:47 +0000 (UTC) (envelope-from steve@sohara.org) Received: from uk1rly2283.eechost.net (relay01.mail.uk1.eechost.net [217.69.40.69]) by mx1.freebsd.org (Postfix) with ESMTP id 405A686F for ; Mon, 31 Aug 2015 17:29:46 +0000 (UTC) (envelope-from steve@sohara.org) Received: from [88.151.27.41] (helo=smtp.marelmo.com) by uk1rly2283.eechost.net with esmtpa (Exim 4.72) (envelope-from ) id 1ZWSe9-0005Vz-9y for freebsd-questions@freebsd.org; Mon, 31 Aug 2015 18:13:29 +0100 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.marelmo.com with smtp (Exim 4.85 (FreeBSD)) (envelope-from ) id 1ZWSe8-000DC9-SZ for freebsd-questions@freebsd.org; Mon, 31 Aug 2015 17:13:28 +0000 Date: Mon, 31 Aug 2015 18:13:26 +0100 From: Steve O'Hara-Smith To: freebsd-questions@freebsd.org Subject: Re: Replacing Drive with SSD Message-Id: <20150831181326.ec4d6bdab2d2f10de5f7aa22@sohara.org> In-Reply-To: <55E4865B.1000104@sneakertech.com> References: <20150829220311.c7608be1.freebsd@edvax.de> <55E45973.2050103@sneakertech.com> <55E4865B.1000104@sneakertech.com> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; amd64-portbld-freebsd10.1) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Auth-Info: 24227@permanet.ie (plain) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 17:29:47 -0000 On Mon, 31 Aug 2015 12:52:43 -0400 Quartz wrote: > > That is exactly what TRIM is, a mechanism for a filesystem to tell the > > drive "this block is no longer in use". Otherwise, the only thing the > > drive has to determine whether a block is in use is whether it has ever > > been written. > > But, from what I understand, it doesn't exactly tell the firmware "this > is no longer in use" so much as it says "you can zero this right now if > you want" > > > >> Simply assuming based on if or how long ago it was written to can't > >> possibly be a workable solution. I'm not convinced that leaving large > >> chunks of the drive 'free' has any effect on wear leveling. > > > > It provides a pool of blocks that have not and will not be written. > > Bbut how does the drive "know" that those blocks are not allocated by a > partition somewhere and are safe to use as spares? It's not like the > drive firmware reads into the partition table or anything. AIUI that with SSDs and the like it's more that physical blocks are not allocated to logical block addresses until the block is written to for the first time, so all blocks are spares until they are used and they can be returned to the spare pool using TRIM. All this with the proviso that the physical blocks used in the SSD generally cover many logical blocks. -- Steve O'Hara-Smith