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.
Reported-by: [email protected]
Signed-off-by: Eric Sandeen <[email protected]>
---
diff --git a/resize/resize2fs.c b/resize/resize2fs.c
index 5a1eb2a..2d4a14f 100644
--- a/resize/resize2fs.c
+++ b/resize/resize2fs.c
@@ -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;
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.
On Mon, Nov 9, 2009 at 12:57 PM, Eric Sandeen <[email protected]> wrote:
> 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.
>
> Reported-by: [email protected]
> Signed-off-by: Eric Sandeen <[email protected]>
> ---
>
> diff --git a/resize/resize2fs.c b/resize/resize2fs.c
> index 5a1eb2a..2d4a14f 100644
> --- a/resize/resize2fs.c
> +++ b/resize/resize2fs.c
> @@ -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;
>
>
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"
Michael Evans wrote:
> 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
> #!/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"
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.
On Mon, Nov 09, 2009 at 02:57:04PM -0600, Eric Sandeen wrote:
> 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.
>
> Reported-by: [email protected]
> Signed-off-by: Eric Sandeen <[email protected]>
Thanks, applied to the e2fsprogs maint branch.
- Ted