From owner-cvs-all@FreeBSD.ORG Mon Dec 17 15:26:22 2007 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93C0D16A417; Mon, 17 Dec 2007 15:26:22 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8EB13C447; Mon, 17 Dec 2007 15:26:21 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 294A67ECBD; Mon, 17 Dec 2007 10:26:21 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 17 Dec 2007 10:26:21 -0500 X-Sasl-enc: VFENc1Bv6NsrnYj/yZ2S6TGiIdnIDCPHeuImXsII4XAK 1197905180 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 3FD1C3603; Mon, 17 Dec 2007 10:26:20 -0500 (EST) Message-ID: <4766951B.8090504@incunabulum.net> Date: Mon, 17 Dec 2007 15:26:19 +0000 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Poul-Henning Kamp References: <11419.1197903331@critter.freebsd.dk> In-Reply-To: <11419.1197903331@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, "Bruce M. Simpson" , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sbin/atacontrol atacontrol.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2007 15:26:22 -0000 Poul-Henning Kamp wrote: >> Aha, I understand now. CFA and SATA vendors have gone off in two >> separate directions: >> * PATA and SATA drives, for a few years now, have tended to rewrite one >> cylinder at a time, which implies erasing the data on that cylinder. >> > > Everybody denies this in the stongest possibly way whenever I ask them, > so far I have not seen this claim substantiated by any fact or person > who would be in a position to know. > Is this a case of blanket denial on the part of the disk manufacturers? The feedback I've seen in FreeBSD forums regarding ATA write caching tends to back up your original assertion. I wonder if vendor neutral, reproducible, scientific research has been conducted into this issue. > >> * NAND Flash devices should not have their sectors erased unless >> absolutely necessary, to implement wear levelling. >> > > Wrong, almost exactly the opposite in fact: > > Flash devices using wear-levelling should have data erased as soon as > possible to give the wear-levelling the maximum amount of information > and available space to work with. > Ah, let me rephrase, I meant: * NAND Flash embedded ATA controllers should not erase sectors containing data unless absolutely necessary, to implement wear levelling. * BIO_DELETE provides the necessary hint from the OS, by way of the ATA CFA ERASE command, to tell the flash controller that the upper layer consumer of the blocks has marked the data as being erased. * The NAND flash ATA controller is *then* in a position to know how best to implement that wear levelling as the OS has told it "I'm not using these sectors any more". Is this a correct summary? [I came across an alternative to JFFS2 awhile back whose name escapes me, which might work for the SDIO arm stuff imp was playing with.] BMS