Date:   Wed, 8 Aug 2018 13:58:48 +0200
From:   Lukas Czerner <lczerner@...hat.com>
To:     Patrick Dung <mpatdung@...il.com>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: inode 7 frequently have problem when I run fsck

Just FYI the problem is solved, the following is my response to the bz
and my e2fsck patch should be on the list by now.


Patrick,

turns out that the fact that you specified -g4096 made the ratio of
metadata+reserved metadata to block in group so small that e2fsprogs
decided it was better to use meta_bg instead.

Unfortunately it did not remove the resize_inode feature (which is
incompatible with meta_bg) which led to this problem. The good news is
that this was fixed upstream with the latest release 1.44.3 with commit:

commit 42e77d5db53e3ec09b5dc507169d15de219799e3 Author: Jan Kara

    libext2fs: don't create filesystems with meta_bg and resize_inode

    ext2fs_initialize() may end up enabling meta_bg feature for
    filesystem which have resize_inode. Such combination is invalid to
    make sure we disable resize_inode when enabling meta_bg.


Unfortunately e2fsck still fails to recognize that this combination is
not valid and will attempt to recreate the resize_inode. This needs to
be fixed. Meanwhile you can remove the resize_inode yourself by using
tune2fs

tune2fs -O ^resize_inode <device>

then you'll need to run e2fsck to free the blocks resize_inode had
allocated.

However in your case, having suboptimal fs layout because of -g4096 I'd
recommend recreating the file system. This time I'd also recommend to
leave it to defaults unless you really know exactly what you're doing
and how it's going to affect the functionality and performance.

Thanks!
-Lukas


On Sun, Jul 29, 2018 at 11:05:22AM +0800, Patrick Dung wrote:
> Hello,
> 
> I have a file system that frequently have problem when I run fsck.
> I remembered that I should have unmount it when I finish using it in
> last time (about two months ago)
> 
> When I mount it today, it does not have error message that there is
> unclean umount.I only noticed this drive is using the
> journal_checksum_v3 feature, not sure it it is related.
> 
> $ sudo fsck.ext4 /dev/sdb1
> e2fsck 1.44.2 (14-May-2018)
> storage1 has gone 62 days without being checked, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Inode 7 has illegal block(s).  Clear<y>? yes
> Illegal block #1042 (1252450111) in inode 7.  CLEARED.
> Illegal block #1043 (1934033907) in inode 7.  CLEARED.
> Illegal block #1075 (2131231744) in inode 7.  CLEARED.
> Illegal block #1107 (1288373248) in inode 7.  CLEARED.
> Illegal block #1123 (3089105920) in inode 7.  CLEARED.
> Illegal block #1155 (2389050368) in inode 7.  CLEARED.
> Illegal block #1171 (3824747520) in inode 7.  CLEARED.
> Illegal block #1187 (2595292160) in inode 7.  CLEARED.
> Illegal block #1203 (2943026176) in inode 7.  CLEARED.
> Illegal block #1235 (1430389760) in inode 7.  CLEARED.
> Illegal block #1251 (2182349824) in inode 7.  CLEARED.
> Too many illegal blocks in inode 7.
> Clear inode<y>? yes
> Restarting e2fsck from the beginning...
> Resize inode not valid.  Recreate<y>? yes
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> Free blocks count wrong for group #1 (420, counted=421).
> Fix<y>? yes
> Free blocks count wrong (341766565, counted=341766566).
> Fix<y>? yes
> 
> storage1: ***** FILE SYSTEM WAS MODIFIED *****
> storage1: 105794/244189184 files (2.2% non-contiguous),
> 634987610/976754176 blocks
> 
> Output of dumpe2fs
> Filesystem volume name:   storage1
> Last mounted on:          /mnt1
> Filesystem UUID:          7184ae75-3871-4c69-9a10-bc93449207dc
> Filesystem magic number:  0xEF53
> Filesystem revision #:    1 (dynamic)
> Filesystem features:      has_journal ext_attr resize_inode dir_index
> filetype meta_bg extent 64bit flex_bg sparse_super large_file
> huge_file dir_nlink extra_isize metadata_csum
> Filesystem flags:         signed_directory_hash
> Default mount options:    user_xattr acl
> Filesystem state:         clean
> Errors behavior:          Continue
> Filesystem OS type:       Linux
> Inode count:              244189184
> Block count:              976754176
> Reserved block count:     9767541
> Free blocks:              341766566
> Free inodes:              244083390
> First block:              0
> Block size:               4096
> Fragment size:            4096
> Group descriptor size:    64
> Reserved GDT blocks:      1024
> Blocks per group:         4096
> Fragments per group:      4096
> Inodes per group:         1024
> Inode blocks per group:   64
> Flex block group size:    16
> Filesystem created:       Sun Jul 30 12:55:21 2017
> Last mount time:          Sun May 27 12:16:43 2018
> Last write time:          Sun Jul 29 10:33:17 2018
> Mount count:              0
> Maximum mount count:      -1
> Last checked:             Sun Jul 29 10:33:17 2018
> Check interval:           3888000 (1 month, 2 weeks, 1 day)
> Next check after:         Wed Sep 12 10:33:17 2018
> Lifetime writes:          3437 GB
> Reserved blocks uid:      0 (user root)
> Reserved blocks gid:      0 (group root)
> First inode:              11
> Inode size:               256
> Required extra isize:     32
> Desired extra isize:      32
> Journal inode:            8
> Default directory hash:   half_md4
> Directory Hash Seed:      21c957bc-ae01-49d4-a87e-e46a31812fd1
> Journal backup:           inode blocks
> Checksum type:            crc32c
> Checksum:                 0x8a2b32da
> Journal features:         journal_incompat_revoke journal_64bit
> journal_checksum_v3
> Journal size:             1024M
> Journal length:           262144
> Journal sequence:         0x00009564
> Journal start:            0
> Journal checksum type:    crc32c
> Journal checksum:         0x26cc12b4
> 
> I had also upload the full output of dumpe2fs in here:
> https://drive.google.com/open?id=1GYHviU29jCxVzuXfy9Y0BP0OerPTYQYj
> 
> Thanks!
> Patrick

Powered by blists - more mailing lists