[Top] [All Lists]

Re: [PATCH] [RFC v2] xfs: byte range buffer dirty region tracking

To: Mark Tinguely <tinguely@xxxxxxx>
Subject: Re: [PATCH] [RFC v2] xfs: byte range buffer dirty region tracking
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 4 Jun 2015 08:44:49 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <556F0CE0.8080402@xxxxxxx>
References: <1432865777-14616-1-git-send-email-david@xxxxxxxxxxxxx> <556F0CE0.8080402@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Jun 03, 2015 at 09:19:12AM -0500, Mark Tinguely wrote:
> On 05/28/15 21:16, Dave Chinner wrote:
> >Discussion:
> >
> >I think that we will eventually need to track multiple regions - 3
> >is probably sufficient - because the nature of directory operations
> >are that just about every operation modifies a header in the buffer,
> >a tail section in the buffer and then some number of bytes/regions
> >in the middle of the buffer.
> Nod to the idea.
> What made you change from your original idea of using 4 regions to 3
> regions?

3 or 4 regions make little difference. header, body and tail is most
common for random directory modifications, so whether we have 1 or 2
body regions won't make much difference once more than a couple of
modifications are made to the same directory block. Indeed, I'm not
sure that we even need multiple regions - the log bandwidth and log
item memcpy overhead hasn't changed very much even on large
directory buffers with a single region...


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>