Skip to contentSkip to conversation

resize2fs: exit fix_sb_journal_backup early for external journal

PATCH Applied Eric Sandeen 3 participants 6 messages Nov 9, 2009 – Nov 13, 2009

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 resize2fs: exit fix_sb_journal_backup early for external journal

Resizing a filesystem with an external journal fails when it tries to read inode 0:

# touch testfs
# truncate testfs 1342177280
# touch testjournal
# truncate testjournal 134217728
# mke2fs -O journal_dev testjournal 
# losetup /dev/loop0 testjournal 
# mkfs.ext4 -J device=/dev/loop0 testfs 127680
# resize2fs testfs 
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on testfs to 327680 (4k) blocks.
resize2fs: Illegal inode number while trying to resize testfs
Please run 'e2fsck -fy testfs' to fix the filesystem
after the aborted resize operation.

I think the right, simple thing to do is just bail out early for an external journal here, as there are no backup blocks to update.

---

resize/resize2fs.c +4 -0
index 5a1eb2a..2d4a14f 100644
@@ -1887,6 +1887,10 @@ static errcode_t fix_sb_journal_backup(ext2_filsys fs)
 	if (!(fs->super->s_feature_compat & EXT3_FEATURE_COMPAT_HAS_JOURNAL))
 		return 0;
 
+	/* External journal? Nothing to do. */
+	if (fs->super->s_journal_dev && !fs->super->s_journal_inum)
+		return 0;
+
 	retval = ext2fs_read_inode(fs, fs->super->s_journal_inum, &inode);
 	if (retval)
 		return retval;
#1 lore raw

Thank you for the patch, I've refined your testcase:

#!/bin/sh
touch testfs
truncate -s2G testfs
touch testjournal
truncate -s128M testjournal
LOLOG=losetup -f
losetup "${LOLOG}" testjournal
mke2fs -O journal_dev "${LOLOG}"
LOFS=losetup -f
losetup "${LOFS}" testfs
mkfs.ext4 -J device="${LOLOG}" "${LOFS}" 127680
echo -e "\n\nThis will fail\n"
resize2fs "${LOFS}"
echo -e "\nFsck to clear\n"
fsck -fy "${LOFS}"
echo -e "\n\nIf run in the build dir of a the current version/git checkout with the patch applied and build... ./resize/resize2fs will work.\n"
./resize/resize2fs "${LOFS}"
losetup -d "${LOLOG}"
losetup -d "${LOFS}"

Insert data checks/etc as desired.

Quoted 32 lines · Eric Sandeen

Resizing a filesystem with an external journal fails when it tries to read inode 0:

# touch testfs
# truncate testfs 1342177280
# touch testjournal
# truncate testjournal 134217728
# mke2fs -O journal_dev testjournal
# losetup /dev/loop0 testjournal
# mkfs.ext4 -J device=/dev/loop0 testfs 127680
# resize2fs testfs
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on testfs to 327680 (4k) blocks.
resize2fs: Illegal inode number while trying to resize testfs
Please run 'e2fsck -fy testfs' to fix the filesystem
after the aborted resize operation.

I think the right, simple thing to do is just bail out early for an external journal here, as there are no backup blocks to update.

---

resize/resize2fs.c +0 -0
index 5a1eb2a..2d4a14f 100644

resize/resize2fs.c static errcode_t fix_sb_journal_backup(ext2_filsys fs) · line 1896

Quoted 10 lines
resize/resize2fs.c +4 -0
@@ -1887,6 +1887,10 @@ static errcode_t fix_sb_journal_backup(ext2_filsys fs)
        if (!(fs->super->s_feature_compat & EXT3_FEATURE_COMPAT_HAS_JOURNAL))
                return 0;
 
+       /* External journal? Nothing to do. */
+       if (fs->super->s_journal_dev && !fs->super->s_journal_inum)
+               return 0;
+
        retval = ext2fs_read_inode(fs, fs->super->s_journal_inum, &inode);
        if (retval)
                return retval;

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw

I've run this test case a few times on my system. It looks like it's the right thing to do, but before I run it on a drive that actually has data I care about I'd like to make sure it's doesn't have some kind of unforeseen side effects.

#!/bin/sh
touch testfs
truncate -s1500M testfs
touch testjournal
truncate -s128M testjournal
LOLOG=losetup -f
losetup "${LOLOG}" testjournal
mke2fs -O journal_dev "${LOLOG}"
LOFS=losetup -f
losetup "${LOFS}" testfs
mkfs.ext4 -J device="${LOLOG}" "${LOFS}" 200000
mkdir /tmp/testfs
mount "${LOFS}" /tmp/testfs
echo "Filesystem mounted, copying /usr/src/linux/ to (try to) fill the device." find /usr/src/linux/ -depth -print0 | cpio -p0mud /tmp/testfs pushd /tmp/testfs
echo "Generating checksums"
find ./ -type f -print0 | xargs -0I = md5sum = > /tmp/check.md5 popd
df | grep "/tmp/testfs"
wc /tmp/check.md5
umount /tmp/testfs
fsck -fy "${LOFS}"
resize2fs "${LOFS}"
fsck -fy "${LOFS}"
./resize/resize2fs "${LOFS}"
mount "${LOFS}" /tmp/testfs
pushd /tmp/testfs
df | grep "/tmp/testfs"
md5sum -c /tmp/check.md5 | sed '/OK[\r\n]*$/d'
if [ "$?" == "0" ] ; then echo "MD5 check PASSED" ; fi
popd
umount /tmp/testfs
rm -rf /tmp/testfs /tmp/check.md5
losetup -d "${LOLOG}"
losetup -d "${LOFS}"
rm testfs testjournal
echo "Cleanup Complete"

#3 lore raw
Quoted 4 lines · Michael Evans

I've run this test case a few times on my system. It looks like it's the right thing to do, but before I run it on a drive that actually has data I care about I'd like to make sure it's doesn't have some kind of unforeseen side effects.

I really think the patch is fine, but you can wait 'til Ted merges it for the official stamp of approval... :)

-eric

Quoted 38 lines

#!/bin/sh
touch testfs
truncate -s1500M testfs
touch testjournal
truncate -s128M testjournal
LOLOG=losetup -f
losetup "${LOLOG}" testjournal
mke2fs -O journal_dev "${LOLOG}"
LOFS=losetup -f
losetup "${LOFS}" testfs
mkfs.ext4 -J device="${LOLOG}" "${LOFS}" 200000
mkdir /tmp/testfs
mount "${LOFS}" /tmp/testfs
echo "Filesystem mounted, copying /usr/src/linux/ to (try to) fill the device." find /usr/src/linux/ -depth -print0 | cpio -p0mud /tmp/testfs pushd /tmp/testfs
echo "Generating checksums"
find ./ -type f -print0 | xargs -0I = md5sum = > /tmp/check.md5 popd
df | grep "/tmp/testfs"
wc /tmp/check.md5
umount /tmp/testfs
fsck -fy "${LOFS}"
resize2fs "${LOFS}"
fsck -fy "${LOFS}"
./resize/resize2fs "${LOFS}"
mount "${LOFS}" /tmp/testfs
pushd /tmp/testfs
df | grep "/tmp/testfs"
md5sum -c /tmp/check.md5 | sed '/OK[\r\n]*$/d'
if [ "$?" == "0" ] ; then echo "MD5 check PASSED" ; fi
popd
umount /tmp/testfs
rm -rf /tmp/testfs /tmp/check.md5
losetup -d "${LOLOG}"
losetup -d "${LOFS}"
rm testfs testjournal
echo "Cleanup Complete"

#4 lore raw

I agree it looks like the right thing to do there, but I'm not sure if there's some other effect it's supposed to have.

However just based on that small section I should probably be safe if I use the latest RC kernel (for other ext4 reasons that sound important) and then do an fsck -f after the resize.

Applied
#5 lore raw
In reply to Eric Sandeen
Quoted 17 lines · Eric Sandeen

Resizing a filesystem with an external journal fails when it tries to read inode 0:

# touch testfs
# truncate testfs 1342177280
# touch testjournal
# truncate testjournal 134217728
# mke2fs -O journal_dev testjournal 
# losetup /dev/loop0 testjournal 
# mkfs.ext4 -J device=/dev/loop0 testfs 127680
# resize2fs testfs 
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on testfs to 327680 (4k) blocks.
resize2fs: Illegal inode number while trying to resize testfs
Please run 'e2fsck -fy testfs' to fix the filesystem
after the aborted resize operation.
Quoted 6 lines

I think the right, simple thing to do is just bail out early for an external journal here, as there are no backup blocks to update.

Thanks, applied to the e2fsprogs maint branch.

- Ted