<div dir="ltr"><div>Hi,</div><div><br></div><div>it seems you got it right! I don't know if you read email I sent you before posting to the mailing list, but I accidentally diagnosed the cause... :) I've noticed that inodes fsck warned me about, at least ones that I checked, all have all four timestamps latest in 2010...</div>
<div><br></div><div>The filesystem has maximum 1281998848 inodes, which is timestamp in august 2010. I don't know how it got that big, I think I did not specified big value initially. But I've resized it couple of times. BTW what is default of group size / inode count ratio? Mine ratio is not at the maximum you mentioned, but it is not that far.</div>
<div><br></div><div>So almost sure it is false positive by the code / bug in e2fsck/pass1.c around line 1070 in current version. I want to be sure that all these errors were caused by this, so can you please send me promptly patched version? I can easily patch it myself by some fixed condition, but I don't want miss something important... BTW maybe you can compare i_dtime with filesystem creation timestamp, so you dont have to put fixed number there.</div>
<div><br></div><div>BTW I dont know specifics of ext3, I just looked at sources of kernel driver and e2fsprogs now. But what indicates that inode is / was created and valid ? (I did not need it to find problematic test you mentioned, did not see it in part of code I look at and it is not apparent to me from definition of <span class="" style="font-size:13px;color:rgb(131,0,0)">struct</span><span style="color:rgb(0,0,0);font-size:13px"> ext3_inode</span>).</div>
<div><br></div><div>Thanks.</div><div><br></div><div class="gmail_extra"><div>Patrik</div>
<br><br><div class="gmail_quote">2014-04-18 22:20 GMT+02:00 <span dir="ltr"><<a href="mailto:tytso@mit.edu" target="_blank">tytso@mit.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>On Fri, Apr 18, 2014 at 06:56:57PM +0200, Patrik Horník wrote:<br>
><br>
> yesterday I experienced following problem with my ext3 filesystem:<br>
><br>
> - I had ext3 filesystem of the size of a few TB with journal. I correctly<br>
> unmounted it and it was marked clean.<br>
><br>
> - I then ran fsck.etx3 -f on it and it did not find any problem.<br>
><br>
> - After increasing size of its LVM volume by 1.5 TB I resized the<br>
> filesystem by resize2fs lvm_volume and it finished without problem.<br>
><br>
> - But fsck.ext3 -f immediately after that showed "Inodes that were part of<br>
> a corrupted orphan linked list found." and many thousands of "Inode XXX was<br>
> part of the orphaned inode list." I did not accepted fix. According to<br>
> debugfs all the inodes I check from these reported orphaned inodes (I<br>
> checked only some from beginning of list of errors) have size 0.<br>
<br>
</div>Can you send the output of dumpe2fs -h? I'm curious how many inodes<br>
you had after the resize, and what file system features might have<br>
been enabled on your file system.<br>
<br>
If the only file system corruption errors that you saw were from about<br>
the corrupted orphan inode list, then things are probably OK.<br>
<br>
What this error message means is that there are d_time values which<br>
look like they belong to inode numbers (as opposed to number of<br>
seconds since January 1, 1970). So if you ran the system where the<br>
clock was set incorrectly, so that the time was January 1, 1970, and<br>
you delete a lot of files, you can run into this error --- it's<br>
basically a sanity check that we put in a long time ago to catch<br>
potential file system bugs caused by a corrupted orphan inode list.<br>
<br>
I'm thinking that we should turn off this check if the e2fsck.conf<br>
"broken_system_lock" is enabled, since if the system has a busted<br>
system clock, this can end up triggering a bunch of scary warnings.<br>
<br>
In any case, when you grew the size of the file system, this also<br>
increased the number of inodes, which means it would increase the<br>
sensitivity of hitting this bug. It's also possible that if you<br>
created your file system with the number of inodes per block group<br>
close to the maximum (assuming an average file size 4k, which would be<br>
highly wasteful of space, so it' s not the default), that you ended up<br>
with the maximum number of inodes exceeding 1.2 or 1.3 billion inodes,<br>
at which point it would trigger a false positive. (And indeed, I<br>
should probably put in a fix to e2fsprogs so that if a file system<br>
does have more than 1.2 billion inodes, to disable this check.)<br>
<br>
Cheers,<br>
<br>
- Ted</blockquote></div></div></div>