From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH 2/3] GFS2: Drop initial reservation if too small
Date: Tue, 17 Sep 2013 13:33:09 -0400 (EDT) [thread overview]
Message-ID: <1861488338.16777852.1379439189927.JavaMail.root@redhat.com> (raw)
In-Reply-To: <1379409897.2722.10.camel@menhir>
----- Original Message -----
| Hi,
|
| On Mon, 2013-09-16 at 15:10 -0500, Bob Peterson wrote:
| > Before this patch, function gfs2_inplace_reserve would grab a blocking
| > lock on the rgrp glock. This is not necessary if we already know that
| > rgrp doesn't have enough blocks to satisfy the request. This patch
| > makes the function drop the inadequate reservation so that a more
| > suitable rgrp may be found (with a try lock). This is not a very
| > important thing to do, and it still requires a blocking lock to remove
| > the reservation. However, it allows us to further simplify the code
| > with a future patch because after this patch, we will know for sure
| > that the reservation will not be in the rgrp's reservations tree
| > unless it has enough blocks.
| > ---
| > fs/gfs2/rgrp.c | 45 +++++++++++++++++++++++++++++++++++++++++----
| > 1 file changed, 41 insertions(+), 4 deletions(-)
| >
| This looks like the wrong thing to do. If we have a reservation, then we
| should always use it until it is used up, otherwise we are adding more
| fragmentation when we do not need to. The requested amount is supposed
| to be the number of blocks that we'd like to have in an ideal world, but
| provided we can supply the minimum number of blocks (currently 1) then
| there is no need to drop the reservation.
|
| Also, I don't want to reintroduce the try locks now that we've
| eliminated them from this part of the code, since that brings back
| another set of problems. Maybe I'm not understanding what the intent is
| here though as despite the comment above, the patches don't appear to
| actually bring the try lock back.
|
| postmark only tends to write very small files, depending on what
| settings it is being run with, so will likely not gain from the
| reservations work at all. The main reason for using it is to ensure that
| we don't get a regression rather than expecting it to show any
| improvements.
|
| Steve.
Hi,
Actually, unless I'm reading the code wrong, it already does this.
If this is the wrong thing to do, we need to change the logic.
In today's gfs2_inplace_reserve, there's a check:
if (rs->rs_rbm.rgd->rd_free_clone >= requested) {
ip->i_rgd = rs->rs_rbm.rgd;
return 0;
}
(otherwise it gets rejected)
This similarly rejects any pre-existing reservation if it doesn't satisfy
the requested size. What I was trying to do here is preserve the existing
logic. If it's wrong and we need to change it, that's fine, but I have
doubts that it will pass all the testing; when I was working on the
block reservations code, I believe I tried that and got into some nasty
problems. Still, it may be worth trying again.
Regards,
Bob Peterson
Red Hat File Systems
next prev parent reply other threads:[~2013-09-17 17:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-16 20:10 [Cluster-devel] [GFS2 PATCH 1/3] GFS2: Eliminate a goto from function gfs2_inplace_reserve Bob Peterson
2013-09-16 20:10 ` [Cluster-devel] [GFS2 PATCH 2/3] GFS2: Drop initial reservation if too small Bob Peterson
2013-09-17 9:24 ` Steven Whitehouse
2013-09-17 17:33 ` Bob Peterson [this message]
2013-09-16 20:10 ` [Cluster-devel] [GFS2 PATCH 3/3] GFS2: Don't insert into reservations tree unless rgrp has enough blocks Bob Peterson
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=1861488338.16777852.1379439189927.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).