linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: linux-ext4@vger.kernel.org
Cc: sandeen@redhat.com
Subject: [PATCH 0/3] Fix resize2fs data/filesystem corruption bugs
Date: Sat, 18 Apr 2009 23:03:45 -0400	[thread overview]
Message-ID: <1240110228-22781-1-git-send-email-tytso@mit.edu> (raw)


These patches fix some nasty resize2fs bugs when growing or shrinking
ext4 filesystems off-line.  Eric, you'll probably want get these
patches into Fedora's e2fsprogs before F11 goes live.

The test case I've been using for these patches are as follows.

#!/bin/sh
mke2fs -i 8192 -b 1024 -t ext4 /dev/closure/testext4 1048576
mount /dev/closure/testext4 /mnt
cd /mnt
mkdir 1 2 3 4
cd 1; tar xjf /usr/projects/uml/shars/linux-2.6.11.tar.bz2; cd ..
cd 2; tar xjf /usr/projects/uml/shars/linux-2.6.11.tar.bz2; cd ..
cd 3; tar xjf /usr/projects/uml/shars/linux-2.6.11.tar.bz2; cd ..
cd 4; tar xjf /usr/projects/uml/shars/linux-2.6.11.tar.bz2; cd ..
cd /
umount /mnt
e2fsck -f /dev/closure/testext4

Then try resizing the filesystem smaller or larger.  With e2fsprogs
1.41.4, "resize2fs -M -p /dev/closure/testext4" will just plain fail in
the middle with the resize operation:

# /sbin/resize2fs  -M -p /dev/closure/testext4
resize2fs 1.41.4 (27-Jan-2009)
Resizing the filesystem on /dev/closure/textext4 to 863610 (1k) blocks.
Begin pass 2 (max = 116149)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 128)
Scanning inode table          XXXXXXXXXXXXXXXXXXXX/sbin/resize2fs: No space left on device while trying to resize /dev/closure/textext4

The bugs fixed include potentially overwriting part of the existing
inode table when shrinking the filesystem, and potentially overwriting
in-use data blocks when growing the filesystem.  So these are pretty
serious errors, and means an e2fsprogs 1.41.5 will be coming out real
soon now.

With these patches, I've resized the filesystem and then run a CRC
checksum test across the unpacked 2.6.11 source tree.  (Why 2.6.11?
Because it was what I happened to have handy on my laptop at the time. :-)

						- Ted



             reply	other threads:[~2009-04-19  3:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-19  3:03 Theodore Ts'o [this message]
2009-04-19  3:03 ` [PATCH 1/3] resize2fs: Fix data corruption bug when growing an ext4 filesystem off-line Theodore Ts'o
2009-04-19  3:03   ` [PATCH 2/3] resize2fs: Fix data corruption bug when shrinking the inode table for ext4 Theodore Ts'o
2009-04-19  3:03     ` [PATCH 3/3] resize2fs: Fix corruption bug impacting ext4 filesystems with uninit_bg Theodore Ts'o
2009-04-21 23:57 ` [PATCH 0/3] Fix resize2fs data/filesystem corruption bugs 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=1240110228-22781-1-git-send-email-tytso@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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).