All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 60667] New: resizing ext4 with small block size corrupts filesystem
Date: Wed, 31 Jul 2013 15:56:26 +0000	[thread overview]
Message-ID: <bug-60667-13602@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=60667

            Bug ID: 60667
           Summary: resizing ext4 with small block size corrupts
                    filesystem
           Product: File System
           Version: 2.5
    Kernel Version: 3.10.4
          Hardware: x86-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@kernel-bugs.osdl.org
          Reporter: trevor.w.jones@gmail.com
        Regression: No

I have a filesystem with lots of small files (gentoo portage tree) that I
created with a 1024 block size.  I resized that filesystem and it resulted in
corruption.  I am able to consistently reproduce it by resizing a filesystem
that was created 512mb with 1024 block size up to 1g.  My data was still
recoverable, and fortunately it was nothing that can not easily be reproduced,
however I could not get it to fsck cleanly.



dagron ~ # lvcreate -L 1g resizetest vgtest
  Volume group "resizetest" not found
dagron ~ # lvcreate -L 1g -n resizetest vgtest
  Logical volume "resizetest" created
dagron ~ # mkfs.ext4 -b 1024 -i 2048 /dev/vgtest/resizetest 524288
mke2fs 1.42.7 (21-Jan-2013)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
262144 inodes, 524288 blocks
26214 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67633152
64 block groups
8192 blocks per group, 8192 fragments per group
4096 inodes per group
Superblock backups stored on blocks: 
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done 

dagron ~ # mount /dev/vgtest/resizetest /mnt/tmp
dagron ~ # df /mnt/tmp
Filesystem                    1K-blocks  Used Available Use% Mounted on
/dev/mapper/vgtest-resizetest    442212  2318    409584   1% /mnt/tmp
dagron ~ # resize2fs /dev/mapper/vgtest-resizetest
resize2fs 1.42.7 (21-Jan-2013)
Filesystem at /dev/mapper/vgtest-resizetest is mounted on /mnt/tmp; on-line
resizing required
old_desc_blocks = 2, new_desc_blocks = 4
The filesystem on /dev/mapper/vgtest-resizetest is now 1048576 blocks long.

dagron ~ # df /mnt/tmp
Filesystem                    1K-blocks         Used   Available Use% Mounted
on
/dev/mapper/vgtest-resizetest    900808 -21474833672 21475683202    - /mnt/tmp
dagron ~ # umount /mnt/tmp
dagron ~ # e2fsck /dev/vgtest/resizetest
e2fsck 1.42.7 (21-Jan-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for inode table
e2fsck: Group descriptors look bad... trying backup blocks...
/dev/vgtest/resizetest: recovering journal
e2fsck: unable to set superblock flags on /dev/vgtest/resizetest


/dev/vgtest/resizetest: ***** FILE SYSTEM WAS MODIFIED *****

/dev/vgtest/resizetest: ********** WARNING: Filesystem still has errors
**********

dagron ~ # uname -a
Linux dagron 3.10.4 #13 SMP Tue Jul 30 14:45:19 EDT 2013 x86_64 AMD Athlon(tm)
II X4 620 Processor AuthenticAMD GNU/Linux
dagron ~ # e2fsck -V
e2fsck 1.42.7 (21-Jan-2013)
        Using EXT2FS Library version 1.42.7, 21-Jan-2013

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2013-07-31 15:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-31 15:56 bugzilla-daemon [this message]
2015-02-13 14:02 ` [Bug 60667] resizing ext4 with small block size corrupts filesystem bugzilla-daemon
2015-02-13 15:58 ` bugzilla-daemon

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=bug-60667-13602@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.