On Thu, Jul 26, 2007 at 09:05:15AM -0400, Chris Mason wrote:
> On Thu, 26 Jul 2007 04:36:39 +0200
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> [ are state trees a good idea? ]
>
> > > One thing it gains us is finding the start of the cluster. Even if
> > > called by kswapd, the state tree allows
On Thu, 26 Jul 2007 04:36:39 +0200
Nick Piggin <[EMAIL PROTECTED]> wrote:
[ are state trees a good idea? ]
> > One thing it gains us is finding the start of the cluster. Even if
> > called by kswapd, the state tree allows writepage to find the start
> > of the cluster and send down a big bio (pr
On 26 Jul 2007, at 03:36, Nick Piggin wrote:
On Wed, Jul 25, 2007 at 10:10:07PM -0400, Chris Mason wrote:
On Thu, 26 Jul 2007 03:37:28 +0200
Nick Piggin <[EMAIL PROTECTED]> wrote:
One advantage to the state tree is that it separates the state from
the memory being described, allowing a sim
On Wed, Jul 25, 2007 at 10:10:07PM -0400, Chris Mason wrote:
> On Thu, 26 Jul 2007 03:37:28 +0200
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> >
> > > One advantage to the state tree is that it separates the state from
> > > the memory being described, allowing a simple kmap style interface
> >
On Thu, 26 Jul 2007 03:37:28 +0200
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > One advantage to the state tree is that it separates the state from
> > the memory being described, allowing a simple kmap style interface
> > that covers subpages, highmem and superpages.
>
> I suppose so, although
On Wed, Jul 25, 2007 at 08:18:53AM -0400, Chris Mason wrote:
> On Wed, 25 Jul 2007 04:32:17 +0200
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Having another tree to store block state I think is a good idea as I
> > said in the fsblock thread with Dave, but I haven't clicked as to why
> > it is
On Wed, 25 Jul 2007 04:32:17 +0200
Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 24, 2007 at 07:25:09PM -0400, Chris Mason wrote:
> > On Tue, 24 Jul 2007 23:25:43 +0200
> > Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> >
> > The tree is a critical part of the patch, but it is also the
> > ea
On Tue, Jul 24, 2007 at 07:25:09PM -0400, Chris Mason wrote:
> On Tue, 24 Jul 2007 23:25:43 +0200
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> The tree is a critical part of the patch, but it is also the easiest to
> rip out and replace. Basically the code stores a range by inserting
> an obje
On Tue, 24 Jul 2007 23:25:43 +0200
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-24 at 16:13 -0400, Trond Myklebust wrote:
> > On Tue, 2007-07-24 at 16:00 -0400, Chris Mason wrote:
> > > On Tue, 10 Jul 2007 17:03:26 -0400
> > > Chris Mason <[EMAIL PROTECTED]> wrote:
> > >
> > > > Th
On Tue, 2007-07-24 at 16:13 -0400, Trond Myklebust wrote:
> On Tue, 2007-07-24 at 16:00 -0400, Chris Mason wrote:
> > On Tue, 10 Jul 2007 17:03:26 -0400
> > Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> > > This patch aims to demonstrate one way to replace buffer heads with a
> > > few extent trees
On Tue, 2007-07-24 at 16:00 -0400, Chris Mason wrote:
> On Tue, 10 Jul 2007 17:03:26 -0400
> Chris Mason <[EMAIL PROTECTED]> wrote:
>
> > This patch aims to demonstrate one way to replace buffer heads with a
> > few extent trees. Buffer heads provide a few different features:
> >
> > 1) Mapping
On Thu, 12 Jul 2007 00:00:28 -0700
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> On Tuesday 10 July 2007 14:03, Chris Mason wrote:
> > This patch aims to demonstrate one way to replace buffer heads with
> > a few extent trees...
>
> Hi Chris,
>
> Quite terse commentary on algorithms and data stru
On Tuesday 10 July 2007 14:03, Chris Mason wrote:
> This patch aims to demonstrate one way to replace buffer heads with a
> few extent trees...
Hi Chris,
Quite terse commentary on algorithms and data structures, but I suppose
that is not a problem because Jon has a whole week to reverse engineer
13 matches
Mail list logo
