* EXT4: unsupported inode size: 4096
@ 2020-02-06 15:35 Herbert Poetzl
2020-02-06 22:52 ` Theodore Y. Ts'o
2020-02-06 22:55 ` Andreas Dilger
0 siblings, 2 replies; 3+ messages in thread
From: Herbert Poetzl @ 2020-02-06 15:35 UTC (permalink / raw)
To: linux-ext4; +Cc: linux-kernel
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
[33700.299204] EXT4-fs (loop0): unsupported inode size: 4096
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
Note that the logical block size is also 512 on many SATA
drives which have a physical block size of 4096.
Any ideas how to address this problem and get the file-
systems to mount under Linux 5.5?
Many thanks in advance,
Herbert
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: EXT4: unsupported inode size: 4096
2020-02-06 15:35 EXT4: unsupported inode size: 4096 Herbert Poetzl
@ 2020-02-06 22:52 ` Theodore Y. Ts'o
2020-02-06 22:55 ` Andreas Dilger
1 sibling, 0 replies; 3+ messages in thread
From: Theodore Y. Ts'o @ 2020-02-06 22:52 UTC (permalink / raw)
To: linux-ext4, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On Thu, Feb 06, 2020 at 04:35:42PM +0100, Herbert Poetzl 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.
Thanks for the bug report! This was actually a regression caused by
recent security fix (which landed after 5.5, but which backported to
the 5.5 stable kernel).
The following should fix things. Please let me know if you still have
problems after applying this fix.
- Ted
[-- Attachment #2: 0001-ext4-fix-support-for-inode-sizes-1024-bytes.patch --]
[-- Type: text/x-diff, Size: 2713 bytes --]
From e0c963ab41e21bea32565a36654523687be3e7f0 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Thu, 6 Feb 2020 17:35:01 -0500
Subject: [PATCH] ext4: fix support for inode sizes > 1024 bytes
A recent commit, 9803387c55f7 ("ext4: validate the
debug_want_extra_isize mount option at parse time"), moved mount-time
checks around. One of those changes moved the inode size check before
the blocksize variable was set to the blocksize of the file system.
After 9803387c55f7 was set to the minimum allowable blocksize, which
in practice on most systems would be 1024 bytes. This cuased file
systems with inode sizes larger than 1024 bytes to be rejected with a
message:
EXT4-fs (sdXX): unsupported inode size: 4096
Fixes: 9803387c55f7 ("ext4: validate the debug_want_extra_isize mount option at parse time")
Cc: stable@kernel.org
Reported-by: Herbert Poetzl <herbert@13thfloor.at>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
---
fs/ext4/super.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 88b213bd32bc..eebcf9b9272d 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3814,6 +3814,15 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
*/
sbi->s_li_wait_mult = EXT4_DEF_LI_WAIT_MULT;
+ blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size);
+ if (blocksize < EXT4_MIN_BLOCK_SIZE ||
+ blocksize > EXT4_MAX_BLOCK_SIZE) {
+ ext4_msg(sb, KERN_ERR,
+ "Unsupported filesystem blocksize %d (%d log_block_size)",
+ blocksize, le32_to_cpu(es->s_log_block_size));
+ goto failed_mount;
+ }
+
if (le32_to_cpu(es->s_rev_level) == EXT4_GOOD_OLD_REV) {
sbi->s_inode_size = EXT4_GOOD_OLD_INODE_SIZE;
sbi->s_first_ino = EXT4_GOOD_OLD_FIRST_INO;
@@ -3831,6 +3840,7 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
ext4_msg(sb, KERN_ERR,
"unsupported inode size: %d",
sbi->s_inode_size);
+ ext4_msg(sb, KERN_ERR, "blocksize: %d", blocksize);
goto failed_mount;
}
/*
@@ -4033,14 +4043,6 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
if (!ext4_feature_set_ok(sb, (sb_rdonly(sb))))
goto failed_mount;
- blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size);
- if (blocksize < EXT4_MIN_BLOCK_SIZE ||
- blocksize > EXT4_MAX_BLOCK_SIZE) {
- ext4_msg(sb, KERN_ERR,
- "Unsupported filesystem blocksize %d (%d log_block_size)",
- blocksize, le32_to_cpu(es->s_log_block_size));
- goto failed_mount;
- }
if (le32_to_cpu(es->s_log_block_size) >
(EXT4_MAX_BLOCK_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) {
ext4_msg(sb, KERN_ERR,
--
2.24.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: EXT4: unsupported inode size: 4096
2020-02-06 15:35 EXT4: unsupported inode size: 4096 Herbert Poetzl
2020-02-06 22:52 ` Theodore Y. Ts'o
@ 2020-02-06 22:55 ` Andreas Dilger
1 sibling, 0 replies; 3+ messages in thread
From: Andreas Dilger @ 2020-02-06 22:55 UTC (permalink / raw)
To: Herbert Poetzl, Ted Tso; +Cc: linux-ext4, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]
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
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-02-06 22:55 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-06 15:35 EXT4: unsupported inode size: 4096 Herbert Poetzl
2020-02-06 22:52 ` Theodore Y. Ts'o
2020-02-06 22:55 ` Andreas Dilger
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 NNTP newsgroup(s).