From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: vm/fs meetup details Date: Thu, 05 Jul 2007 17:40:57 -0400 Message-ID: <468D6569.6050606@redhat.com> References: <20070705040138.GG32240@wotan.suse.de> <468D303E.4040902@redhat.com> <137D15F6-EABE-4EC1-A3AF-DAB0A22CF4E3@oracle.com> <20070705212757.GB12413810@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Zach Brown , Nick Piggin , Anton Altaparmakov , Suparna Bhattacharya , Christoph Hellwig , Hugh Dickins , Jared Hulbert , Chris Mason , "Martin J. Bligh" , Trond Myklebust , Neil Brown , Joern Engel , Miklos Szeredi , Mingming Cao , Linux Memory Management List , linux-fsdevel@vger.kernel.org To: David Chinner Return-path: Received: from mx1.redhat.com ([66.187.233.31]:47240 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756854AbXGEVpF (ORCPT ); Thu, 5 Jul 2007 17:45:05 -0400 In-Reply-To: <20070705212757.GB12413810@sgi.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org David Chinner wrote: > On Thu, Jul 05, 2007 at 01:40:08PM -0700, Zach Brown wrote: >>> - repair driven design, we know what it is (Val told us), but >>> how does it apply to the things we are currently working on? >>> should we do more of it? >> I'm sure Chris and I could talk about the design elements in btrfs >> that should aid repair if folks are interested in hearing about >> them. We'd keep the hand-waving to a minimum :). > > And I'm sure I could provide a counterpoint by talking about > the techniques we've used improving XFS repair speed and > scalability without needing to change any on disk formats.... Sounds like that could be an interesting discussion. Especially when trying to answer questions like: "At what filesystem size will the mitigating fixes no longer be enough?" and "When will people start using filesystems THAT big?" :) -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <468D6569.6050606@redhat.com> Date: Thu, 05 Jul 2007 17:40:57 -0400 From: Rik van Riel MIME-Version: 1.0 Subject: Re: vm/fs meetup details References: <20070705040138.GG32240@wotan.suse.de> <468D303E.4040902@redhat.com> <137D15F6-EABE-4EC1-A3AF-DAB0A22CF4E3@oracle.com> <20070705212757.GB12413810@sgi.com> In-Reply-To: <20070705212757.GB12413810@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: David Chinner Cc: Zach Brown , Nick Piggin , Anton Altaparmakov , Suparna Bhattacharya , Christoph Hellwig , Hugh Dickins , Jared Hulbert , Chris Mason , "Martin J. Bligh" , Trond Myklebust , Neil Brown , Joern Engel , Miklos Szeredi , Mingming Cao , Linux Memory Management List , linux-fsdevel@vger.kernel.org List-ID: David Chinner wrote: > On Thu, Jul 05, 2007 at 01:40:08PM -0700, Zach Brown wrote: >>> - repair driven design, we know what it is (Val told us), but >>> how does it apply to the things we are currently working on? >>> should we do more of it? >> I'm sure Chris and I could talk about the design elements in btrfs >> that should aid repair if folks are interested in hearing about >> them. We'd keep the hand-waving to a minimum :). > > And I'm sure I could provide a counterpoint by talking about > the techniques we've used improving XFS repair speed and > scalability without needing to change any on disk formats.... Sounds like that could be an interesting discussion. Especially when trying to answer questions like: "At what filesystem size will the mitigating fixes no longer be enough?" and "When will people start using filesystems THAT big?" :) -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org