Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756157AbYHGMoX (ORCPT ); Thu, 7 Aug 2008 08:44:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751561AbYHGMoG (ORCPT ); Thu, 7 Aug 2008 08:44:06 -0400 Received: from rgminet02.oracle.com ([148.87.113.119]:56730 "EHLO rgminet02.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751360AbYHGMoF (ORCPT ); Thu, 7 Aug 2008 08:44:05 -0400 Subject: Re: Btrfs v0.16 released From: Chris Mason To: Peter Zijlstra Cc: linux-btrfs , linux-kernel , linux-fsdevel In-Reply-To: <1218100464.8625.9.camel@twins> References: <1217962876.15342.33.camel@think.oraclecorp.com> <1218100464.8625.9.camel@twins> Content-Type: text/plain Date: Thu, 07 Aug 2008 06:39:57 -0400 Message-Id: <1218105597.15342.189.camel@think.oraclecorp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1614 Lines: 44 On Thu, 2008-08-07 at 11:14 +0200, Peter Zijlstra wrote: > On Tue, 2008-08-05 at 15:01 -0400, Chris Mason wrote: > > > There are still more disk format changes planned, but we're making every > > effort to get them out of the way as quickly as we can. You can see the > > major features we have planned on the development timeline: > > > > http://btrfs.wiki.kernel.org/index.php/Development_timeline > > Just took a peek, seems to be slightly out of date as it still lists the > single mutex thingy. Thanks, I thought I had removed all the references to it on that page, but there was one left. > > Also, how true is the IO-error and disk-full claim? > We still don't handle disk full. The IO errors are handled most of the time. If a checksum doesn't match or the lower layers report an IO error, btrfs will use an alternate mirror of the block. If there is no alternate mirror, the caller gets EIO and in the case of a failed csum, the page is zero filled (actually filled with ones so I can find bogus pages in an oops). Metadata is duplicated by default even on single spindle drives, so this means that metadata IO errors are handled as long as the other mirror is happy. If mirroring is off or both mirrors are bad, we currently get into trouble. data pages work better, those errors bubble up to userland just like in other filesystems. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/