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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.