lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 8 Dec 2016 21:40:36 -0800
From:   Simon Matthews <simon.d.matthews@...il.com>
To:     linux-ext4@...r.kernel.org
Subject: Fwd: Filesystem size problem.

Forwarding this to linux-ext4 list because the linux-admin list
appears to be very quiet.

Please accept my apologies in advance if this is the wrong forum for
this question!

Simon

---------- Forwarded message ----------
From: Simon Matthews <simon.d.matthews@...il.com>
Date: Thu, Dec 8, 2016 at 8:29 PM
Subject: Filesystem size problem.
To: linux-admin@...r.kernel.org


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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ