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
>
next prev parent 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).