linux-ext4 - Re: inode 7 frequently have problem when I run fsck

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]

Message-ID: <20180729175553.GC21725@thunk.org>
Date:   Sun, 29 Jul 2018 13:55:53 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Patrick Dung <mpatdung@...il.com>, G@...nk.org
Cc:     linux-ext4@...r.kernel.org
Subject: Re: inode 7 frequently have problem when I run fsck

Hi Patrick,

Inode #7 is the resize inode.  This inode reserves specific blocks in
the file system which are used in case you want to grow the size of
the file system.  This may not be possible at all --- for example, if
the file system is located on a single disk or flash device, and it is
already using all of the space on the disk.  However, the amount of
space used for to allow the file system to be dynamically grown is
small, so we just reserve it by default.

Being able to dynamically grow the file system is most useful if the
file system is located on a LVM (Logical Volume Manager), or some
other kind of dynmically resizable device.  (For example, if you were
using a VM on Google Compute Engine, a Persistent Disk can be grown
while the VM is running.  The same is true with Amazon Web Service's
EBS disk.)

So the thing is that the indirect block used by the resize inode
(inode #7) is located at specific block.  This block is getting
corrupted, and this is what causing these reports:

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

Now, *how* and *why* the resize inode got corrupted is an interesting
question.  It could be a hardware problem, or it could be some kind of
kernel bug (in ext4, or some device driver that corrupting memory,
etc.)

If it is always the same block, that would tend to suggest some kind
of hardware problem, but that's just a guess.

   	    	     	 	       - Ted