fsck.ext4 - Error determining size of the physical device: File too large

Bug #521648 reported by Marcus Sæthershagen on 2010-02-14
80
This bug affects 13 people
Affects Status Importance Assigned to Milestone
e2fsprogs (Ubuntu)
Medium
Unassigned

Bug Description

Binary package hint: e2fsprogs

Linux hq 2.6.31-19-server #56-Ubuntu SMP Thu Jan 28 03:40:48 UTC 2010 x86_64 GNU/Linux

lsb_release -rd
Description: Ubuntu 9.10
Release: 9.10

e2fsprogs:
  Installed: 1.41.9-1ubuntu3
  Candidate: 1.41.9-1ubuntu3
  Version table:
 *** 1.41.9-1ubuntu3 0
        500 http://no.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Trying to run fsck.ext4 /dev/md0, and get this error:

e2fsck 1.41.9 (22-Aug-2009)
Error determining size of the physical device: File too large

mdadm -D
/dev/md0:
        Version : 00.90
  Creation Time : Sun Dec 13 01:45:00 2009
     Raid Level : raid6
     Array Size : 17581607424 (16767.13 GiB 18003.57 GB)
  Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB)
   Raid Devices : 11
  Total Devices : 11
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Feb 14 10:39:58 2010
          State : clean
 Active Devices : 11
Working Devices : 11
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 64K

           UUID : 113f3752:1a58e4ce:b3e5aabb:1a00ee34
         Events : 0.1159384

    Number Major Minor RaidDevice State
       0 8 97 0 active sync /dev/sdg1
       1 8 113 1 active sync /dev/sdh1
       2 8 81 2 active sync /dev/sdf1
       3 8 145 3 active sync /dev/sdj1
       4 8 1 4 active sync /dev/sda1
       5 8 17 5 active sync /dev/sdb1
       6 8 33 6 active sync /dev/sdc1
       7 8 49 7 active sync /dev/sdd1
       8 8 65 8 active sync /dev/sde1
       9 8 129 9 active sync /dev/sdi1
      10 8 161 10 active sync /dev/sdk1

Changed in e2fsprogs (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium

Does this affect resize2fs as well? If/when this is fixed, will it be safe to run resize2fs, or might that have a similar issue?

Denis Ladin (denladin) wrote :

I have the same problem. I grow a RAID-5 from 9 to 14 discs. Then I wished to check up and expand a file system.

# fsck.ext4 /dev/md0
e2fsck 1.41.9 (22-Aug-2009)
Error determining size of the physical device: File too large

# resize2fs /dev/md0
resize2fs 1.41.9 (22-Aug-2009)
resize2fs: File too large while trying to determine filesystem size

The additional information:
Ubuntu Server 9.10

# uname -a
Linux server4 2.6.31-20-server #57-Ubuntu SMP Mon Feb 8 09:59:59 UTC 2010 x86_64 GNU/Linux

# cat /proc/mdstat
md0 : active raid5 sdn[13] sdc[10] sdk[6] sda[9] sdj[7] sdi[0] sdb[11] sdg[3] sdd[8] sdh[1] sdm[12] sdf[4] sdl[5] sde[2]
      19046800448 blocks level 5, 64k chunk, algorithm 2 [14/14] [UUUUUUUUUUUUUU]

# blkid /dev/md0
/dev/md0: UUID="a90d6711-627e-4d01-8db7-3f2fa16de2f9" TYPE="ext4"

HELP ME!
After reboot, /dev/md0 cannot mount !

# mount -t ext4 /dev/md0 /mnt/md0/
mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

# dmesg | tail
[ 1058.903277] EXT4-fs (md0): ext4_check_descriptors: Checksum for group 12173 failed (14802!=36012)
[ 1058.903295] EXT4-fs (md0): group descriptors corrupted!

# fsck.ext4 /dev/md0
e2fsck 1.41.9 (22-Aug-2009)
Error determining size of the physical device: File too largee: File too large

Denis Ladin (denladin) wrote :

Dist-upgrade to "Lucid Lynx" does not help.

# fsck.ext4 /dev/md0
e2fsck 1.41.10 (10-Feb-2009)
Error determining size of the physical device: File too large

# resize2fs /dev/md0
resize2fs 1.41.10 (10-Feb-2009)
resize2fs: File too large while trying to determine filesystem size

# uname -a
Linux server4 2.6.32-14-server #20-Ubuntu SMP Sat Feb 20 06:29:47 UTC 2010 x86_64 GNU/Linux

R212-1 (maxutov) wrote :

^))))

Theodore Ts'o (tytso) wrote :

I can backport the enough code from the devel branch to the maint branch so that e2fsck will at least not fail --- however, the support for 64-bit block numbers is never going to be in the e2fsprogs 1.41.x series. I hope to get a WIP test snapshot of 1.42 for people to play with, but I'm not going to recommend it for production use in the near future. Guinea pigs who understand that while the 64-bit e2fsprogs branch has been lightly tested, but that it might eat all of their data and so they promise to keep _extra_ backups (we are all doing regular backups, right? ---- nod your heads, then put it on your todo list for next week :-) are of course welcome to try it.

So in answer to your question, I can make it so that e2fsck will at least work in e2fsprogs 1.41.11, but resize2fs is not going to work beyond 16TB, at least for now.

Best regards,

-- Ted

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package e2fsprogs - 1.41.11-1ubuntu1

---------------
e2fsprogs (1.41.11-1ubuntu1) lucid; urgency=low

  * Merge from Debian unstable, remaining changes:
    - Do not build-depend on dietlibc-dev, which is universe.
    - Do now allow pkg-create-dbgsym to operate on this package.
    - Always use external libblkid and libuuid from util-linux, rather than
      building our own.
    - Includes debian/control in the source package to force the above.
    - Build with -O2 on powerpc to avoid a suspected toolchain bug
      (LP: #450214).
    - Do not include /etc/e2fsck.conf and remove on upgrade.
    (Fixes LP: #521648, #537483, #530071)

e2fsprogs (1.41.11-1) unstable; urgency=medium

  * New upstream release
  * Add Heimdal function com_right_r() to libcom_err (Closes: #558910)
  * Allow e2fsck to run even if the physical device has more than 2**32 blocks
  * Debugfs's "logdump -b <blk>" now properly shows the allocation status
    of the block <blk>. (Closes: #564084)
  * Make e2fsck's "the filesystem is mounted" message is now more scary
    to hopefully dissuade users from thinking, "surely that message
    doesn't apply to *me*" :-(
  * e2fsck -n will now always open the file system read-only. We now
    disallow certain combination of options which previously were manual
    exceptions; this is bad because it causes users to think they are
    smarter than they really are. So "-n -c", "-n -l", "-n -L", and
    "-n -D" are no longer supported.
  * If the partition is badly aligned, have mke2fs just print a warning
    message and continue. Previously mke2fs would ask to confirm, and
    this broke distro installation scripts.
  * Fix a bug in libext2fs caused the creation of very large journals
    for ext4 to be _very_ slow.
  * E2fsck now understands the EOFBLOCKS_FL flag which will be used in
    2.6.34 kernels to make e2fsck not complain about blocks deliberately
    fallocated() beyond an inode's i_size.
  * Fix a bug in e2fsck which could cause e2fsck -D to corrupt
    non-indexed directories. (Closes: #572453)
  * debian/rules: can be compiled statically with stack protector now.
    (Closes: #573923)
  * Update debian policy compliance to 3.8.4
 -- Scott James Remnant <email address hidden> Mon, 22 Mar 2010 17:48:20 +0000

Changed in e2fsprogs (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments