From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Thu, 12 Jan 2017 10:49:15 -0500 (EST) Subject: [Cluster-devel] [PATCH 2/5] gfs2_edit savemeta: Don't read rgrp blocks twice In-Reply-To: <20170110143446.14419-3-anprice@redhat.com> References: <20170110143446.14419-1-anprice@redhat.com> <20170110143446.14419-3-anprice@redhat.com> Message-ID: <135078219.10029221.1484236155175.JavaMail.zimbra@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----- 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 | --- 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