From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pat LaVarre Subject: Re: srfs - a new file system. Date: 24 Oct 2003 15:22:18 -0600 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1067030538.16779.31.camel@patehci2> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: adilger@clusterfs.com, jaharkes@cs.cmu.edu, bulb@ucw.cz, linux-fsdevel@vger.kernel.org Return-path: Received: from email-out2.iomega.com ([147.178.1.83]:10236 "EHLO email.iomega.com") by vger.kernel.org with ESMTP id S262637AbTJXVWj (ORCPT ); Fri, 24 Oct 2003 17:22:39 -0400 To: tzachar@cs.bgu.ac.il In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org > I'm confident I actually do experience these failures because often I > > work in comparative, raid-like measures. When I see one drive and > > another disagree about what I wrote, then whenever I trust my write and > > diff and read tools I must conclude one or both of the HDD's is wrong. > > so, wont a f/s that can guarantee (and prove) its stability be nice? Yes. > thats what we're aiming at ;) > > since these kind of errors are transient (meaning, in an infinite > execution time only a finite number of errors occur), srfs should be > capable to deal with'em. Good. Help the mass market more accurately measure how often the millions of commodity HDD's actually do fail to read back what was written, and you'll get noticed, I think. We can't know til after we run this experiment? We might actually discover that in fact quantifying the real experience of HDD failure does gives us numbers roughly equal to the more easily repeated, carefully controlled, therefore useless to me, laboratory results that some folk prefer to publish. Pat LaVarre