All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH] [TRY #2] GFS2: Implement a "bitmap has no extents longer than X" scheme
Date: Mon, 11 Nov 2013 09:01:22 -0500 (EST)	[thread overview]
Message-ID: <131364899.20160689.1384178482510.JavaMail.root@redhat.com> (raw)
In-Reply-To: <1383823945.2712.4.camel@menhir>

----- Original Message -----
| Hi,
| 
| On Wed, 2013-11-06 at 10:59 -0500, Bob Peterson wrote:
| > Hi,
| > 
| > This is a slightly revised version of a patch I recently sent out:
| > 
| > Before this patch, we used a bit, GBF_FULL, to determine when a bitmap
| > was full. With the preceding patch, we started accepting block
| > reservations smaller than the ideal size, which requires a lot more
| > parsing of the bitmaps. To reduce the amount of bitmap searching, this
| > patch implements a scheme whereby each rgrp keeps track of the point
| > at this multi-block reservations will fail.
| > 
| The first two patches look good. However this one I'm still not so keen
| on. I'd much prefer if we can avoid dropping the GBF_FULL support at
| bitmap level if the new test is at rgrp level. It doesn't look like that
| is too tricky to achieve either - all we need to do is to not remove the
| GBF_FULL support since there doesn't appear to be any conflict between
| the two mechanisms.
| 
| The net result is a diffstat that looks like this:
| 
| [root at chywoon linux-2.6]# diffstat -p1 ./patch3.diff
|  fs/gfs2/incore.h |    1 +
|  fs/gfs2/lops.c   |    1 +
|  fs/gfs2/rgrp.c   |   32 ++++++++++++++++++++++++++------
|  3 files changed, 28 insertions(+), 6 deletions(-)
| 
| as opposed to your patch which looks like:
| 
| [root at chywoon linux-2.6]# diffstat -p1 ../bob-a-3.mbox
|  fs/gfs2/incore.h |    2 +-
|  fs/gfs2/lops.c   |    2 +-
|  fs/gfs2/rgrp.c   |   53
|  ++++++++++++++++++++++++++---------------------------
|  3 files changed, 28 insertions(+), 29 deletions(-)
| 
| So there would be fewer changes overall. I've given this a quick spin,
| and it hasn't broken yet, so let me know what you think,
| 
| Steve.
Hi Steve,

I've done a fair amount of testing on your new patch that does not remove
the GBF_FULL flag, and it seems to work fine. Go ahead and use that one
instead of mine.

IOW: ACK

Regards,

Bob Peterson
Red Hat File Systems



  reply	other threads:[~2013-11-11 14:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1450086691.17689091.1383753511869.JavaMail.root@redhat.com>
2013-11-06 15:59 ` [Cluster-devel] [GFS2 PATCH] [TRY #2] GFS2: Implement a "bitmap has no extents longer than X" scheme Bob Peterson
2013-11-07 11:32   ` Steven Whitehouse
2013-11-11 14:01     ` Bob Peterson [this message]
2013-11-11 14:52       ` Steven Whitehouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=131364899.20160689.1384178482510.JavaMail.root@redhat.com \
    --to=rpeterso@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.