cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 2/5] gfs2_edit savemeta: Don't read rgrp	blocks twice
Date: Thu, 12 Jan 2017 10:49:15 -0500 (EST)	[thread overview]
Message-ID: <135078219.10029221.1484236155175.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20170110143446.14419-3-anprice@redhat.com>

----- Original Message -----
| When savemeta iterates over the rgrps and saves the rgrp header blocks
| it calls save_block which does a bread() for each block despite them
| already being read in earlier. Instead, call save_bh() on the existing
| rgrp buffers. This isn't likely to give a significant performance
| improvement as the duplicate reads would be cache hits but it should
| have a noticeable effect on very large file systems.
| 
| Signed-off-by: Andrew Price <anprice@redhat.com>
| ---

Hi,

IIRC, the reason I coded it the way I did was with the notion that
customers often save their metadata (and send it in) because it's corrupt.
If there's an rgrp block, such as a bitmap, which is corrupt, I wanted
savemeta to save the rgrp blocks regardless of the corruption so we could
see the trash with which it was overwritten. Function gfs2_rgrp_read
checks for corruption and if's not a bitmap, it frees ALL bi_bh buffers;
even the non-corrupt ones.

So we need to ensure that corrupt / blasted rgrps and bitmaps also get
saved, provided their rindex is healthy (which it also might not be).

Perhaps my fears are unfounded? You could verify this by doing:
(1) mkfs.gfs2
(2) blast / zero out a random rgrp or rindex
(3) gfs2_edit savemeta
(4) gfs2_edit printsavedmeta
(5) ensure the output contains the blasted block

Regards,

Bob Peterson
Red Hat File Systems



  reply	other threads:[~2017-01-12 15:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-10 14:34 [Cluster-devel] [PATCH 0/5] gfs2_edit fixes Andrew Price
2017-01-10 14:34 ` [Cluster-devel] [PATCH 1/5] gfs2_edit savemeta: Factor out the bh saving code Andrew Price
2017-01-12 15:42   ` Bob Peterson
2017-01-10 14:34 ` [Cluster-devel] [PATCH 2/5] gfs2_edit savemeta: Don't read rgrp blocks twice Andrew Price
2017-01-12 15:49   ` Bob Peterson [this message]
2017-01-13 14:42     ` Andrew Price
2017-01-13 15:06       ` Bob Peterson
2017-01-10 14:34 ` [Cluster-devel] [PATCH 3/5] gfs2_edit savemeta: Follow lf_next Andrew Price
2017-01-12 15:52   ` Bob Peterson
2017-01-10 14:34 ` [Cluster-devel] [PATCH 4/5] gfs2_edit: Fix unaligned access in restore_init() Andrew Price
2017-01-12 15:58   ` Bob Peterson
2017-01-10 14:34 ` [Cluster-devel] [PATCH 5/5] gfs2_edit: Fix unaligned accesses due to saved_metablock size Andrew Price
2017-01-12 16:02   ` 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=135078219.10029221.1484236155175.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).