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: <CAEtPA0BQUT-0JDxG=0aKt0yf0PnHB-CaX1mAyNKsr7DoB+N-xA@mail.gmail.com>
Date:   Mon, 30 Jul 2018 12:44:46 +0800
From:   Patrick Dung <mpatdung@...il.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     G@...nk.org, linux-ext4@...r.kernel.org
Subject: Re: inode 7 frequently have problem when I run fsck

The problem usually appeared when I did not use the hard drive for a while.
It happened a few times in the past.

When I perform fsck today, it does not appear.
I had checked the SATA hard drive with smartmontools. It passed the
long test and I did not found any problem.

After searching the web. I found Cisco WebEX Node SPA have very
similar error message that I had encountered.
https://www.cisco.com/c/en/us/td/docs/interfaces_modules/shared_port_adapters/install_upgrade/ASR1000/asr_sip_spa_hw/ASRtrbl.pdf
Please check page 7-8 or search for "Inode 7" in the document.

For my hardware, I am using a SATA hard drive over an Avago 9361-8i
storage card.
The SATA hard drive is used as an JBOD disk with write cache enabled
in the hard drive.

Thanks,
Patrick

On Mon, Jul 30, 2018 at 1:55 AM, Theodore Y. Ts'o <tytso@....edu> wrote:
> 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