--- Begin Message ---
Package: src:linux
Version: 3.11.8-1
Severity: normal
Dear Maintainer,
due to the changed kernel configuration to disable the ext2 module and
to enable
CONFIG_EXT4_USE_FOR_EXT23=y
the support for small ext2 file systems has been (accidently?) removed.
Small file systems here are file systems with less than 1024 blocks,
i.e. less than 1 to 4 MeBi depending on the block size. The change has
been introduced between 3.10 and 3.11 in Debian.
When trying to mount such a file system, the following error is printed:
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
> missing codepage or helper program, or other error
> In some cases useful info is found in syslog - try
> dmesg | tail or so
The syslog contains the following line
> EXT4-fs (loop0): bad geometry: block count 1440 exceeds size of device (1048 blocks)
This information is not helpful. While the loss of support for small file
systems is unfortunate, I think the lack of information here is unacceptable.
Such small file systems are still being used, e.g. on removable media or in
the embedded world, thus the bug's severity can be critical for some users.
I do not exactly know what the best fix of this bug is (and thus where to
assign this bug), but some solutions are:
- Revert the kernel configuration to support the ext2 module again
- Print a warning during kernel upgrade
- Print a precise error when mounting fails
- Support such small file systems with the ext4-for-ext2 config
For everyone else who is hit by this problem: As a workaround, an old Debian
kernel (3.10 or older) or a self-compiled kernel with separate ext2 support
can be used to recover the data on such file systems.
> mkfs.ext4 -b 1024 DEVICE
can be used to create an ext4 file system with a minimum size of 1 MeBi as an
alternative.
Cheers
Patrick
--- End Message ---
--- Begin Message ---
>due to the changed kernel configuration to disable the ext2 module and
>to enable
>CONFIG_EXT4_USE_FOR_EXT23=y
>the support for small ext2 file systems has been (accidently?) removed.
>Small file systems here are file systems with less than 1024 blocks,
>i.e. less than 1 to 4 MeBi depending on the block size. The change has
>been introduced between 3.10 and 3.11 in Debian.
It works just fine for me:
<tytso.root@lambda> {/home/tytso}, level 2
501# mke2fs -t ext2 -Fq /tmp/foo.img
<tytso.root@lambda> {/home/tytso}, level 2
502# mount -t ext4 -o loop /tmp/foo.img /mnt
<tytso.root@lambda> {/home/tytso}, level 2
503# df /mnt
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop0 93 14 72 17% /mnt
<tytso.root@lambda> {/home/tytso}, level 2
504# uname -a
Linux lambda 3.12.0-00038-g576a451 #60 SMP Tue Nov 12 00:20:14 EST 2013 x86_64 GNU/Linux
>The syslog contains the following line
>> EXT4-fs (loop0): bad geometry: block count 1440 exceeds size of device (1048 blocks)
>
>This information is not helpful. While the loss of support for small file
>systems is unfortunate, I think the lack of information here is unacceptable.
What this means is that the file system claims to contain 1440 blocks,
but loopback device thinks that it is only 1048 blocks. This is
probably because the underlying file which you are mounting via the
loopback device has a length which is only 1048 times the block size.
(Probably 1k, so run ls -l you'll probably see that the file's i_size
about 1073152 bytes.)
The reason why ext4 has this safety check is because if you mounted
the file system using the ext2 file system, and then tried to write to
it, and the ext2 file system attempted to allocate and then write to
block number 1049, it would get a block device error from the loopback
device layer, and this could potentially result in data loss.
Even if you decide to keep using the 3.10 kernel, and continuing using
the ext2 file system (which is certainly your perogative), I'd suggest
running the following command to avoid the possibility o data loss:
fallocate -l $(expr 1440 \* 1024) /tmp/foo.img
(where you should replace 1024 with the blocksize if it is not 1024
bytes, and you should replace /tmp/foo.img with the name of the
underlying file.)
This command will also solve the problem which you are seeing with
Debian's 3.11 kernel.
BTW, in the future, it might be useful to try a few more experiments
before jumping to a conclusion, which in this case, was hopelessly
wrong. Fortunately you gave enough information that it was possible
to diagnose what was really going on (for which I thank you; what's
most frustrating is when users jump to unnwarranted conclusions, and
then don't give the data which they gathered which led them to make the
jump to their proposed diagnosis.)
Best regards,
- Ted
P.S. I will probably make a change in future kernels so that if that
file system is being mounted read-only, instead of failing the mount
we will print a warning message to the console. I will also try to
make the message a bit clearer.
If you had set up the loop device using losetup, and then run e2fsck,
you would have gotten the following message which would have probably
be clearer (although its proposed diagnosis isn't quite right, since
the most common cause is someone who repartitions the disk without
first shrinking the file system):
The file system size (according to the superblock) is 1440 blocks
The physical size of the device is 1048 blocks.
Either the superblock or the partition table is likely to be corrupt!
Abort?
The reason why e2fsck then asks if you want to abort is the same
reason why ext4 doesn't want to let the mount proceed --- if you
continue, you are likely to do damage to the file system as well as
your data.
E2fsck's message is way too verbose for the kernel console log, but we
can try to do something which is a bit more explanatory than "bad
geometry".
--- End Message ---