From: Theodore Ts'o <tytso@mit.edu>
To: Ext4 Developers List <linux-ext4@vger.kernel.org>
Cc: Theodore Ts'o <tytso@mit.edu>
Subject: [PATCH 1/2] resize2fs: update checksums in the extent tree's relocated block
Date: Sat, 20 Oct 2018 15:14:14 -0400 [thread overview]
Message-ID: <20181020191415.24653-1-tytso@mit.edu> (raw)
When shrinking an file system, and we need to relocate an inode, the
checksums in its extent tree must get updated to reflect its new inode
number. When doing this, we need to do this *after* we update the
extent tree to reflect any blocks which need to be relocated due to
the file system shrink operation.
Otherwise, in the case where only an interior node of the extent tree
needs to get relocated, and none of the entries in that node need to
be adjusted, the checksum for that interior node is updated in the old
copy of that block, and then after the extent tree is updated to use
the new copy of that interior node, the extent tree is left with an
invalid checksum.
This is a relatively rare case, since it requires the following
conditions to be true:
*) The metadata checksum feature must be enabled.
*) An inode needs to be relocated.
*) The inode needs to have an interior node.
*) The block for that interior node needs to be relocated.
*) None of blocks addressed by entries in that interior node needs
to be relocated.
When all of these conditions are true, though, the file system is left
with corrupted with bad checksum for the extent tree block.
Addresses-Launchpad-Bug: 1798562
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: Jean-Baptiste Lallement <jean-baptiste.lallement@ubuntu.com>
---
resize/resize2fs.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/resize/resize2fs.c b/resize/resize2fs.c
index e89405042..38032e5c3 100644
--- a/resize/resize2fs.c
+++ b/resize/resize2fs.c
@@ -2244,31 +2244,20 @@ remap_blocks:
if (retval)
goto errout;
- /* Rewrite extent block checksums with new inode number */
- if (ext2fs_has_feature_metadata_csum(rfs->old_fs->super) &&
- (inode->i_flags & EXT4_EXTENTS_FL)) {
- rfs->old_fs->flags |= EXT2_FLAG_IGNORE_CSUM_ERRORS;
- retval = rewrite_extents(rfs->old_fs, new_inode);
- rfs->old_fs->flags &= ~EXT2_FLAG_IGNORE_CSUM_ERRORS;
- if (retval)
- goto errout;
- }
-
/*
* Update inodes to point to new blocks; schedule directory
* blocks for inode remapping. Need to write out dir blocks
* with new inode numbers if we have metadata_csum enabled.
*/
+ rfs->old_fs->flags |= EXT2_FLAG_IGNORE_CSUM_ERRORS;
if (ext2fs_inode_has_valid_blocks2(rfs->old_fs, inode) &&
(rfs->bmap || pb.is_dir)) {
pb.ino = new_inode;
pb.old_ino = ino;
pb.has_extents = inode->i_flags & EXT4_EXTENTS_FL;
- rfs->old_fs->flags |= EXT2_FLAG_IGNORE_CSUM_ERRORS;
retval = ext2fs_block_iterate3(rfs->old_fs,
new_inode, 0, block_buf,
process_block, &pb);
- rfs->old_fs->flags &= ~EXT2_FLAG_IGNORE_CSUM_ERRORS;
if (retval)
goto errout;
if (pb.error) {
@@ -2283,6 +2272,14 @@ remap_blocks:
if (retval)
goto errout;
}
+
+ /* Fix up extent block checksums with the new inode number */
+ if (ext2fs_has_feature_metadata_csum(rfs->old_fs->super) &&
+ (inode->i_flags & EXT4_EXTENTS_FL)) {
+ retval = rewrite_extents(rfs->old_fs, new_inode);
+ if (retval)
+ goto errout;
+ }
}
if (update_ea_inode_refs &&
@@ -2296,6 +2293,7 @@ remap_blocks:
errout:
reset_com_err_hook();
+ rfs->old_fs->flags &= ~EXT2_FLAG_IGNORE_CSUM_ERRORS;
if (rfs->bmap) {
ext2fs_free_extent_table(rfs->bmap);
rfs->bmap = 0;
--
2.18.0.rc0
next reply other threads:[~2018-10-21 3:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-20 19:14 Theodore Ts'o [this message]
2018-10-20 19:14 ` [PATCH 2/2] tests: move inode and its interior extent tree block Theodore Ts'o
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=20181020191415.24653-1-tytso@mit.edu \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
/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).