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