From: Simon Matthews <simon.d.matthews@gmail.com>
To: linux-admin@vger.kernel.org
Subject: Filesystem size problem.
Date: Thu, 8 Dec 2016 20:29:00 -0800 [thread overview]
Message-ID: <CAEUYfyP7U9L4mB12awB_YWEqixh9R8RpRZXjYTG6mpiZeBW4OQ@mail.gmail.com> (raw)
I have an ext3 filesystem that will not mount under newer versions of
the kernel and I hope someone here can help.
Obviously, one solution is "backup and re-create from scratch". I have
the backups, but I hope that there may be a quicker method to fix the
issues.
The root issue is that the filesystem is very slightly smaller than
the allocated space. The filesystem exists on a MDRAID device and I
think that when I converted the MDRAID to a newer metadata version, it
truncated the available size, slightly. However, how I got here isn't
really important, fixing it now is.
With an slightly older kernel (4.0.5), the filesystem can be mounted.
With 4.4.26, the ext3 support is provided by the ext4 subsystem and it
appears that it will not accept the size issues. dmesg showed this
from the mount attempt:
md5: detected capacity change from 0 to 2839999799296
[ 1162.508338] EXT4-fs (md5): mounting ext3 file system using the ext4 subsystem
[ 1162.508560] EXT4-fs (md5): bad geometry: block count 693359344
exceeds size of device (693359326 blocks)
As I stated, the difference is very small, so it was working OK for a long time.
My attempts to re-size the filesystem did not work. I don't have the
error messages available. Getting the system up and running was more
important at the time.
Apart from "backup and re-create", how can I fix this? What would be
the correct options to use with resize2fs (if that is the correct
approach)? fsck gave me some serious warnings about possibly
destroying the filesystem, so I did not want to do this without
advice.
Simon
reply other threads:[~2016-12-09 4:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CAEUYfyP7U9L4mB12awB_YWEqixh9R8RpRZXjYTG6mpiZeBW4OQ@mail.gmail.com \
--to=simon.d.matthews@gmail.com \
--cc=linux-admin@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 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 read-only IMAP folder(s) and NNTP newsgroup(s).