linux-ext4 - Re: ext4_iget:4740: inode #%ld: block 48: comm find: invalid block

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   21 Jan 2017 11:45:12 -0500
From:   "George Spelvin" <linux@...encehorizons.net>
To:     linux@...encehorizons.net, tytso@....edu
Cc:     jack@...e.cz, linux-ext4@...r.kernel.org
Subject: Re: ext4_iget:4740: inode #%ld: block 48: comm find: invalid block

Ted Ts'o wrote:
On Fri, Jan 20, 2017 at 12:57:23PM -0500, George Spelvin wrote:
>> So I'm guessing the problem is that the required empty system.data
>> attribute is missing (due to the preceding extra_isize changing mess),
>> and if I just created it, everything would magically come back to life
>> 
>> Something like ea_set <inode> system.data ""

> Well, it would still a corrupted, innconsistent inode, in that there
> would still be a block attached to the inode, and i_size would be
> different from the size of the data xattr used by inline_data.  So you
> might as well just clri the inode and rerun fsck, or clri the inode
> and then unlink the directory entry in lost+found.

Er, huh?  I was referring to the following error, which is one of a
dozen inodes I have with this problem (sorry all the Subject: lines have
gotten tangled):

>> Subject: ext4_iget:4740: inode #%ld: block 48: comm find: invalid block
>>
>> debugfs:  stat <1171779>
>> Inode: 1171779   Type: directory    Mode:  0775   Flags: 0x10000000
>> Generation: 2016668288    Version: 0x00000000:00000007
>> User:  1000   Group:   161   Project:     0   Size: 60
>> File ACL: 0    Directory ACL: 0
>> Links: 2   Blockcount: 0
>> Fragment:  Address: 0    Number: 0    Size: 0
>>  ctime: 0x587eff35:6e19953c -- Wed Jan 18 00:37:57 2017
>>  atime: 0x56d5943f:bb6e1344 -- Tue Mar  1 08:08:15 2016
>>  mtime: 0x587eff35:6e19953c -- Wed Jan 18 00:37:57 2017
>> crtime: 0x56d388b6:533e9e7c -- Sun Feb 28 18:54:30 2016
>> Size of extra inode fields: 32
>> Inode checksum: 0x82a01dca
>> Size of inline data: 60
>> 
>> debugfs:  ls <1171779>
>>  1171779  (12) .    1171778  (12) ..    1171954  (12) 0    1171955  (12) 1   
>>  1171956  (12) 2    1171957  (20) 3   

Zero blocks, data apparently safe and sound in the i_blocks field, just
missing (due to getting trashed by buggy i_extra_size changing code)
the system.data ea, and thus i_inline_off == 0 which upsets the kernel.

> You might get it to a state where the kernel isn't explicitly
> complaining any more, but you might end up unmasking other bugs where
> the kernel is further failing to handle an inconsistent inode relating
> to inline_data.

I just want to get it to a state where I can mv the contents into a
replacement directly and then rmdir this one, rather than having to
make a note of the name & inode number of each of the contained files
and then recreate it from the contents of lost+found (which is already
a bit of a swamp I'm wading through).