Message-ID: <55FD6D26.1010706@harvyl.se>
Date:	Sat, 19 Sep 2015 16:11:50 +0200
From:	Johan Harvyl <johan@...vyl.se>
To:	Dave Chinner <david@...morbit.com>,
	Andreas Dilger <adilger@...ger.ca>,
	Theodore Ts'o <tytso@....edu>
Cc:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: resize2fs: Should never happen: resize inode corrupt! - lost key
 inodes

Thanks for the tip about XFS Dave, I have never used it before but I 
decided to give it a try and managed to reproduce my original issue 
there quite quickly.

I took an old 1 TB disk, put it in a USB cradle and attached it to a 
Linux box running Linux 4.1.0-2-amd64, put XFS on it and created a 24T 
sparse file.

# mkfs.xfs /dev/sda1
# truncate test.img -s 24T

Note that this setup shares no hardware components with the box I 
originally noticed the issue on.
The USB cradle is attached to a different box.

Should this be reported in a bug tracker rather than here?

# mkfs.ext4 test.img -i 262144 -m 0 -O 64bit 15627548672k
mke2fs 1.42.13 (17-May-2015)
Discarding device blocks: done
Creating filesystem with 3906887168 4k blocks and 61045248 inodes
Filesystem UUID: 53b8a330-beba-4bc4-ab34-5d57c0f457fb
Superblock backups stored on blocks:
         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 
2654208,
         4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
         102400000, 214990848, 512000000, 550731776, 644972544, 1934917632,
         2560000000, 3855122432

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

# resize2fs -p test.img 19534435840k
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on test.img to 4883608960 (4k) blocks.
Begin pass 2 (max = 6)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 119229)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 5 (max = 8)
Moving inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on test.img is now 4883608960 (4k) blocks long.

# resize2fs -p test.img 23441323008k
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on test.img to 5860330752 (4k) blocks.
Begin pass 2 (max = 6)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 149036)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 5 (max = 14)
Moving inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Should never happen: resize inode corrupt!

# debugfs -c test.img
debugfs 1.42.13 (17-May-2015)
test.img: catastrophic mode - not reading inode or group bitmaps
debugfs:  stat <2>
Inode: 2   Type: bad type    Mode:  0000   Flags: 0x0

So, again the root inode is trashed.

-johan

On 2015-09-19 04:47, Dave Chinner wrote:
> On Wed, Sep 16, 2015 at 07:21:59PM -0600, Andreas Dilger wrote:
>> If you add "-b 1024" to the mke2fs command line to use 1KB instead of 4KB blocks, and reduce the sizes by a factor of 4 does the problem still happen? That would make it easier for someone else to test, since it would only need a 4-5TB disk instead of a 19Tb array.
> Sparse files on XFS using loopback will allow you to simulate
> devices larger than 16TB easily. You can turtle it all the way down,
> too, to create the xfs filesystem on a loopback device on a sparse
> file on ext4....
>
> Doing this sort of thing lets me know, for example, that the
> mkfs.ext4 defaults fail on a 500TB device...
>
> # xfs_io -f -c 'truncate 500t' /mnt/xfs/fs.img
> # ls -lh /mnt/xfs
> total 0
> -rw------- 1 root root 500T Sep 19 12:41 fs.img
> # mkfs.ext4 /mnt/xfs/fs.img
> mke2fs 1.42.13 (17-May-2015)
> /mnt/xfs/fs.img: Cannot create filesystem with requested number of inodes while setting up superblock
> #
>
> Cheers,
>
> Dave.

--
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