From owner-freebsd-fs@FreeBSD.ORG Sun Oct 16 21:13:27 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA5DD106566B for ; Sun, 16 Oct 2011 21:13:27 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id 9017E8FC14 for ; Sun, 16 Oct 2011 21:13:27 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id p9GLDQ4A005157; Sun, 16 Oct 2011 16:13:26 -0500 (CDT) Date: Sun, 16 Oct 2011 16:13:26 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Jeremy Chadwick In-Reply-To: <20111016183003.GA29466@icarus.home.lan> Message-ID: References: <4E9AE725.4040001@gmail.com> <169E82FD-3B61-4CAB-B067-D380D69CDED5@digsys.bg> <4E9B1C1E.7090804@gmail.com> <20111016183003.GA29466@icarus.home.lan> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Sun, 16 Oct 2011 16:13:26 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: [ZFS] Using SSD with partitions X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 21:13:28 -0000 On Sun, 16 Oct 2011, Jeremy Chadwick wrote: > > 2) I would like an explanation as to what "SSDs are more likely than an > MHDD to lose data on a power outage" means exactly (on a technical > level, not something vague) and from where you got this interpretation. The reason is that normal operation of the SSD will move and/or rewrite existing data, which is also likely to be much older than the data currently being written. Common reasons are wear leveling, garbage collection (compacting) and because the block written is not identically sized and aligned with the SSDs native underlying blocks. While data is being re-written, moved, or copied, a copy resides in RAM. A SSD which is more defensive about avoiding corrupting old data is also likely to be slower to synchronously write. There are certainly algorithms (e.g. as used by zfs) which can help an SSD avoid issues. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/