From: Eric Sandeen <sandeen@redhat.com>
To: ext4 development <linux-ext4@vger.kernel.org>
Subject: offline shrink bug w/ testcase & image
Date: Tue, 18 Jun 2013 19:24:36 -0500 [thread overview]
Message-ID: <51C0FA44.3030600@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]
This fs image is problematic for offline resize2fs shrink.
(sorry, it expands to 11G)
# resize2fs <image> 2507776
will lead to corruption[1] because the new size is in the middle
of a block group which has its inode & block bitmaps towards
the end; the bitmaps are left beyond the end of the new filesystem.
I've been trying to find my way around resize2fs, but bleah,
I must admit to being perpetually lost.
I'm not sure there's any simple functionality to handle
this case; does anything else ever need to move bitmaps?
I was looking at blocks_to_move(), and within the "shrinking" loop
I added logic to detect this case:
/* If this (first) group will remain but bitmaps are past EOF, move them */
if (g == ext2fs_group_of_blk2(fs, ext2fs_blocks_count(fs->super))) {
int retval;
blk64_t new_size = ext2fs_blocks_count(fs->super);
if ((IS_BLOCK_BM(fs, g, blk) || IS_INODE_BM(fs, g, blk)) &&
(blk >= new_size)) {
<do something>
}
but at this point I'm not sure what to do. The magic around identifying
& marking & reserving & accounting for moved blocks has me stumped.
I'm happy to keep looking at it but could use some pointers, or if the
fix is obvious to someone, by all means have at it. :)
Thanks,
-Eric
[1] - like this -
e2fsck: Group descriptors look bad... trying backup blocks...
Block bitmap for group 76 is not in group. (block 2508258)
Relocate? yes
Inode bitmap for group 76 is not in group. (block 2508259)
Relocate? yes
One or more block group descriptor checksums are invalid. Fix? yes
Group descriptor 76 checksum is invalid. FIXED.
Pass 1: Checking inodes, blocks, and sizes
Relocating group 76's block bitmap to 2097161...
Relocating group 76's inode bitmap to 2097162...
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: +(2097161--2097162) +(2490368--2490874)
Fix? yes
Free blocks count wrong for group #64 (28187, counted=28185).
Fix? yes
Free blocks count wrong (2430591, counted=2430589).
Fix? yes
testfile: ***** FILE SYSTEM WAS MODIFIED *****
testfile: 11/624624 files (0.0% non-contiguous), 77187/2507776 blocks
[-- Attachment #2: testcase.img.bz2 --]
[-- Type: application/x-bzip2, Size: 25126 bytes --]
next reply other threads:[~2013-06-19 0:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 0:24 Eric Sandeen [this message]
2013-06-19 1:37 ` [PATCH] resize2fs: move bitmaps if shrinking would orphan them Eric Sandeen
2013-06-21 2:47 ` Theodore Ts'o
2013-06-21 14:13 ` Eric Sandeen
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=51C0FA44.3030600@redhat.com \
--to=sandeen@redhat.com \
--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).