From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH v2 2/6] gfs2: Clean up gfs2_adjust_reservation
Date: Mon, 3 Dec 2018 09:32:38 -0500 (EST) [thread overview]
Message-ID: <936623100.38540989.1543847558772.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20181201111019.14363-3-agruenba@redhat.com>
----- Original Message -----
> Unconditionally call gfs2_adjust_reservation in gfs2_alloc_blocks. Move
> the code for updating rd_free and rd_free_clone from gfs2_alloc_blocks
> into gfs2_adjust_reservation.
>
> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
> ---
> fs/gfs2/rgrp.c | 26 ++++++++++++++++----------
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
> index bbcf8b8b2597f..733e21cd4cf25 100644
> --- a/fs/gfs2/rgrp.c
> +++ b/fs/gfs2/rgrp.c
(snip)
> - if (gfs2_rs_active(&ip->i_res))
> - gfs2_adjust_reservation(ip, &rbm, *nblocks);
> + error = gfs2_adjust_reservation(ip, &rbm, *nblocks);
Wait. At what point do we require a reservation for all block allocations?
In today's code, a reservation is not required, so the check for
"if (gfs2_rs_active(&ip->i_res))" is necessary because you can't adjust a
reservation that's not active (in the tree)...being within the tree
determines whether the reservation is active or not.
Yes, I'm looking forward to the day when we require a reservation for all
block allocations as per my original version (this needs to happen to allow
rgrp sharing between processes.) Perhaps a future patch will add the
requirement, but at this point, there's no such requirement, which means
this patch will probably break during a git bisect, no?
We only get into this situation when all bitmaps are nearly full or fragmented
and therefore no reservation will fit the minimum requirements, but we still
need to allow small one-shot block allocations. So we need to do lots of
full-bitmap testing. Or else we need to add this patch only after the
patch that makes reservations mandatory.
Regards,
Bob Peterson
next prev parent reply other threads:[~2018-12-03 14:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-01 11:10 [Cluster-devel] [PATCH v2 0/6] gfs2: Prepare for resource group glock sharing Andreas Gruenbacher
2018-12-01 11:10 ` [Cluster-devel] [PATCH v2 1/6] gfs2: Only use struct gfs2_rbm for bitmap manipulations Andreas Gruenbacher
2018-12-01 11:10 ` [Cluster-devel] [PATCH v2 2/6] gfs2: Clean up gfs2_adjust_reservation Andreas Gruenbacher
2018-12-03 14:32 ` Bob Peterson [this message]
2018-12-03 14:58 ` Andreas Gruenbacher
2018-12-04 22:02 ` Andreas Gruenbacher
2018-12-01 11:10 ` [Cluster-devel] [PATCH v2 3/6] gfs2: Add per-reservation reserved block accounting Andreas Gruenbacher
2018-12-01 11:10 ` [Cluster-devel] [PATCH v2 4/6] gfs2: Add local resource group locking Andreas Gruenbacher
2018-12-01 11:10 ` [Cluster-devel] [PATCH v2 5/6] gfs2: Allow node-wide exclusive glock sharing Andreas Gruenbacher
2018-12-01 11:10 ` [Cluster-devel] [PATCH v2 6/6] gfs2: Introduce resource group sharing Andreas Gruenbacher
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=936623100.38540989.1543847558772.JavaMail.zimbra@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).