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