Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Andreas Dilger <adilger@dilger.ca>
Message-Id: <B9D2B0DE-EAD0-461B-9BA3-E55ADDE38F72@dilger.ca>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_7CDF64A9-C7FD-4E08-9AB4-1843C57439EC";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: EXT4: unsupported inode size: 4096
Date:   Thu, 6 Feb 2020 15:55:04 -0700
In-Reply-To: <20200206153542.GA30449@MAIL.13thfloor.at>
Cc:     linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
To:     Herbert Poetzl <herbert@13thfloor.at>, Ted Tso <tytso@mit.edu>
References: <20200206153542.GA30449@MAIL.13thfloor.at>
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk


--Apple-Mail=_7CDF64A9-C7FD-4E08-9AB4-1843C57439EC
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On Feb 6, 2020, at 8:35 AM, Herbert Poetzl <herbert@13thfloor.at> wrote:
> 
> 
> I recently updated one of my servers from an older 4.19
> Linux kernel to the latest 5.5 kernel mainly because of
> the many filesystem improvements, just to find that some
> of my filesystems simply cannot be mounted anymore.
> 
> The kernel reports: EXT4-fs: unsupported inode size: 4096
> 
> Here is a simple test to reproduce the issue:
> 
>  truncate --size 16G data
>  losetup /dev/loop0 data
>  mkfs.ext4 -I 4096 /dev/loop0
>  mount /dev/loop0 /media

Does this still fail if you also specify "-b 4096"?

> [33700.299204] EXT4-fs (loop0): unsupported inode size: 4096

It looks like this is a bug in the code?  This check is using

3641:	blocksize = sb_min_blocksize(sb, EXT4_MIN_BLOCK_SIZE);

3782:		if ((sbi->s_inode_size < EXT4_GOOD_OLD_INODE_SIZE) ||
3783:		    (!is_power_of_2(sbi->s_inode_size)) ||
3784:		    (sbi->s_inode_size > blocksize)) {
3785:			ext4_msg(sb, KERN_ERR,
3786:			       "unsupported inode size: %d",
3787:			       sbi->s_inode_size);
3788:			goto failed_mount;
3789:		}

which is set from the hardware sector size of the device, while
the ext4 filesystem blocksize is not set until later during mount:

3991:	blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size);

It looks like this was just introduced in commit v5.4-rc3-96-g9803387
"ext4: validate the debug_want_extra_isize mount option at parse time"
so it is a relatively recent change, and looks to be unintentional.
This check was previously on line 4033, after "blocksize" was updated
from the superblock, but it wasn't noticed because it works for all
"normal" filesystems.

I suspect nobody has noticed because having an inode *size* of 4KB
is very unusual, while having an inode *ratio* of 4KB is more normal
(one 256-byte inode for each 4096-byte block in the filesystem).  Was
the use of "-I 4096" intentional, or did you mean to use "-i 4096"?

The only reason to have a 4096-byte inode *size* is if you have a
ton of xattrs for every file and/or you have tiny files (< 3.5KB)
and you are using inline data.

> Note: this works perfectly fine und 4.19.84 and 4.14.145.
> 
> My guess so far is that somehow the ext4 filesystem now
> checks that the inode size is not larger than the logical
> block size of the underlying block device.
> 
>  # cat /sys/block/loop0/queue/logical_block_size
>  512

Yes, this appears to be the case.  We have LOT of filesystems that
are using 1024-byte inodes, but I suspect that most of them are on
devices that report 4096-byte sector size and/or are running older
kernels that have not included this bug.

> Any ideas how to address this problem and get the file-
> systems to mount under Linux 5.5?

Probably the easiest, and likely correct, fix is to move the update
of "blocksize" from line 3991: up to before this check.  There are
a bunch of sanity checks that should also be moved for a proper patch,
but the one-line fix is enough to get your filesystems mounting again.

Cheers, Andreas


--Apple-Mail=_7CDF64A9-C7FD-4E08-9AB4-1843C57439EC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEDb73u6ZejP5ZMprvcqXauRfMH+AFAl48mUgACgkQcqXauRfM
H+ASGg/8DycAju0NbXzVaKiOvovbvjZRyJq7nF6M+KBJevm0928uLjg8qkWvIdXp
Jj1AM93mikp4A/BULggBBpa8wOCIG9Z7bx1tATaQrvQh/3cI5KuWd7ssfTR9INWJ
yzgZ1Y/1vjwiU/YD1i922CK4M3sEwmB5fzrNC/H9HruwHpuMe0ek44lNmsuNPjGh
c+hBkTFlmOPF9n9bW4mr2Da/v1BA+ffSI2NJW3TejR7k6UvvNKWpLrbzheMSMVCf
y5xuD9mWuh/1FL77tdDfDVbPo6VRS6I1JBoz14EUl9mz6IrCWulVgIIi/7NzRviF
onDLo/t3pA/2Yx5G+AAVsIM9tClXXGbNT4WquU2vrO9CdnuRT6rr1pc8vKCz7lch
2US+UhmorTVVd/NeXQMxT2i6NPNbRsoaBqxP5TcLAtp8b5aDAUCUSAHyIEWtoydm
GRPRfXZJauqBYDffGdBWsvsMmepceMC4CMiezfoIWBbfnMfH8wVI+D3qEO6gLDkr
sNm1/dl/7BfIFjF3ndItsgKTVCGIiFgQ86juEDwDwO/+UB9O9K7nngoEe0ZLt/sy
Kn7RLdkOGR689vc/1WArbM31HntWbp88xTe3s2tPlWv4r9hVZebZXFIAYrwvqviS
NrZwqOyjeAmlHWJcqaXQS7kV6tYDpT6Je7weNgZmQA1Xc7Ig12o=
=rKs+
-----END PGP SIGNATURE-----

--Apple-Mail=_7CDF64A9-C7FD-4E08-9AB4-1843C57439EC--