cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Andrew Price <anprice@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 2/4] mkfs.gfs2: Align resource groups to RAID stripes
Date: Thu, 06 Jun 2013 14:04:02 +0100	[thread overview]
Message-ID: <51B088C2.4080701@redhat.com> (raw)
In-Reply-To: <83456593.48037538.1370523424334.JavaMail.root@redhat.com>

On 06/06/13 13:57, Bob Peterson wrote:
> Hi,
>
> | +			/* Squeeze the last 1 or 2 rgs into the remaining space */
> | +			if ((nextaddr < sdp->device.length) && (sdp->device.length - nextaddr >=
> | minrgsz)) {
> | +				rglen = sdp->device.length - nextaddr;
> | +			} else {
> | +				if (sdp->device.length - rgaddr <= maxrgsz)
> | +					rgt->length = sdp->device.length - rgaddr;
> | +				else
> | +					rgt->length = maxrgsz;
> | +				/* This is the last rg */
> | +				nextaddr = 0;
>
> In GFS1, we allowed mix-and-match resource group sizes, but we originally
> designed mkfs.gfs2 to ensure that all rgrps were the same uniform size. This
> usually means some space is wasted at the end of the last resource group.
>
> We did this primarily so that fsck.gfs2 could more easily detect and repair
> damaged resource groups and rindex values. At the time it was designed, I got
> the buy-in of a bunch of developers and we all agreed to it. Since that time,
> I've had to change fsck.gfs2 to take more drastic measures to repair damaged
> resource groups, due to the fact that gfs2_convert can convert a GFS1 file
> system to GFS2, and thus, we can still end up with non-uniform resource groups.
> Many customers were adding storage and doing multiple gfs_grow ops,
> which resulted in metadata sets where the rgrps and rindex were complete chaos.
>
> Still, my assumption has always been: If the file system was made by
> mkfs.gfs2, all resource groups (but the first one) are identical in size.
>
> I think gfs2_grow takes some steps to ensure that new rgrps are also created
> using the same size as the current resource groups. If we don't enforce
> that rule, the rindex could once again become chaos, which means our chances
> of rgrp and rindex repair get worse.
>
> Do we still want to enforce this rule?

Good question. I had assumed that we don't have a rule like that as the 
rindex specifies the rg sizes. My next planned mkfs change is to allow 
the journal creation code to ask for a resource group large enough to 
contain all of a journal's data blocks so that they're always a single 
extent. Returning to enforcing the rule would have implications for that 
plan, too.

Andy

> With the improved rgrp repair algorithms in fsck.gfs2, it may not be
> necessary anymore. I'm not trying to be dogmatic; I'm looking for opinions here.
>
> Regards,
>
> Bob Peterson
> Red Hat File Systems
>



  reply	other threads:[~2013-06-06 13:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-06 12:03 [Cluster-devel] [PATCH 1/4] mkfs.gfs2: Set sunit and swidth from probed io limits Andrew Price
2013-06-06 12:03 ` [Cluster-devel] [PATCH 2/4] mkfs.gfs2: Align resource groups to RAID stripes Andrew Price
2013-06-06 12:06   ` Steven Whitehouse
2013-06-06 12:19     ` Andrew Price
2013-06-06 12:57   ` Bob Peterson
2013-06-06 13:04     ` Andrew Price [this message]
2013-06-06 13:17       ` Bob Peterson
2013-06-06 13:11     ` Steven Whitehouse
2013-06-06 13:30       ` Bob Peterson
2013-06-06 15:17       ` Andrew Price
2013-06-06 12:03 ` [Cluster-devel] [PATCH 3/4] mkfs.gfs2: Create new resource groups on-demand Andrew Price
2013-06-06 13:07   ` Bob Peterson
2013-06-06 13:50     ` Andrew Price
2013-06-06 12:03 ` [Cluster-devel] [PATCH 4/4] mkfs.gfs2: Add align option and update docs Andrew Price
2013-06-06 12:15   ` Steven Whitehouse
2013-06-06 12:45     ` Andrew Price
2013-06-06 12:53       ` Steven Whitehouse
2013-06-06 13:13   ` Bob Peterson
2013-06-06 13:53     ` Andrew Price

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=51B088C2.4080701@redhat.com \
    --to=anprice@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).