From owner-freebsd-stable@FreeBSD.ORG Thu Apr 17 21:46:26 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F191337B401; Thu, 17 Apr 2003 21:46:25 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 112C043FA3; Thu, 17 Apr 2003 21:46:25 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h3I4kMA7086789; Thu, 17 Apr 2003 22:46:23 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 17 Apr 2003 22:46:01 -0600 (MDT) Message-Id: <20030417.224601.38718174.imp@bsdimp.com> To: cdillon@wolves.k12.mo.us From: "M. Warner Losh" In-Reply-To: <20030416100921.U91118@duey.wolves.k12.mo.us> References: <20030415160925.U86854@duey.wolves.k12.mo.us> <3E9D157E.96FD09AE@mindspring.com> <20030416100921.U91118@duey.wolves.k12.mo.us> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-fs@freebsd.org cc: mckusick@McKusick.COM cc: das@freebsd.org cc: tlambert2@mindspring.com cc: freebsd-stable@freebsd.org Subject: Re: PATCH: Forcible delaying of UFS (soft)updates X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 04:46:26 -0000 In message: <20030416100921.U91118@duey.wolves.k12.mo.us> Chris Dillon writes: : quickly. Even with a life of two million write cycles, the : "occasional" 30-second round of updates that happen to write the same : bits over and over will give your flash part a life of only 1.9 years : (2000000 writes * 30 seconds apart = 60000000 seconds to failure). : Also, I doubt you'll actually get 2 million writes out of the average : consumer flash part. I've gotten 10M writes in the lab here on parts that didn't fail. Also, that's 2M writes per cell, and the CF parts wear average. The reason why this happens is because there are typically more than 1 cell per part. However, you are *MUCH* better off logging to a memory file system with cron. Or better yet, not running cron or not logging it at all. We log our stuff to /var/log (and don't bother logging the cron messages) and newsyslog to a small writable partition once a day or so on the average. So using this as an argument to trash fsync is not very strong. There are much better ways to deal with these issues for CF systems. You are much better off doing a read-only / with a small writable partition for things that need to be saved (we call ours /mod). We have a write rate of about 10 per hours, which gives our system an expected life in excess of 20 years. Our company has shipped over 200 flash systems, and we've had 3 flashes fail, all due to infant mortality... Warner