linux-ext4 - Re: Filesystem size problem.

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 12 Dec 2016 15:36:27 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Eric Sandeen <sandeen@...hat.com>
Cc:     Simon Matthews <simon.d.matthews@...il.com>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: Filesystem size problem.

On Dec 9, 2016, at 9:35 PM, Eric Sandeen <sandeen@...hat.com> wrote:
> 
> On 12/9/16 2:29 PM, Andreas Dilger wrote:
>> On Dec 8, 2016, at 10:40 PM, Simon Matthews <simon.d.matthews@...il.com> wrote:
>>> 
>>> 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.
> 
> So the device is now smaller than the filesystem thinks, right?
> 
>> 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.
>> 
>> Running "e2fsck -fy" should fix this.  I'd recommend to use the latest
>> version of e2fsck.
> 
> Reaslly?  e2fsck can change total blocks in the superblock to accomodate a
> shrunken device?  That's a new one for me...

Strange, I thought this case was handled properly by e2fsck.

You could probably fix this with:

# debugfs -R "ssv blocks_count 693359326" /dev/md5
# e2fsck -f /dev/md5

to set the blocks count.  It is unlikely anything is in the last 18 blocks
of the filesystem, and if it is then it is probably already corrupted by
the RAID superblock stored there.

> 
> I don't think so:
> 
> $ truncate --size=101m testfile
> $ mkfs.ext3 testfile
> $ truncate --size=100m testfile
> $ e2fsck -f testfile
> ...
> The physical size of the device is 102400 blocks
> Either the superblock or the partition table is likely to be corrupt!
> Abort<y>? n
> ...
> $ e2fsck -f testfile
> ...
> The physical size of the device is 102400 blocks
> Either the superblock or the partition table is likely to be corrupt!
> Abort<y>? n
> $ e2fsck -f testfile
> ...
> The physical size of the device is 102400 blocks
> Either the superblock or the partition table is likely to be corrupt!
> Abort<y>? n
> 
> etc.
> 
> 
> The proper solution is to fix your block device, not the filesystem;
> it was the block device which was inappropriately shortened.

This may be more easily said than done...

> I don't know if just poking a smaller total blocks number into the
> superblock via debugfs would be safe or not.

It would probably be better to have e2fsck fix this problem itself,
but it is uncommon enough that there is a danger someone will also
shoot themselves in the foot for cases where this isn't working right.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)