<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-04-19 17:48 GMT+02:00 Theodore Ts'o <span dir="ltr"><<a href="mailto:tytso@mit.edu" target="_blank">tytso@mit.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Sat, Apr 19, 2014 at 05:42:12PM +0200, Patrik Horník wrote:<br>
><br>
> Please confirm that this is fully correct solution (for my purpose, not<br>
> elegant clean way for official fix) and it has no negative consequences. It<br>
> seems that way but I did not analyze all code paths the fixed code is in.<br>
<br>
</div>Yes, that's a fine solution.  What I'll probably do is disable the<br>
check if s_inodes_count is greater than s_mkfs_time minus some fudge<br>
value, or if the broken system clock boolean is set.<br>
<div class=""><br>
> BTW were there any other negative consequences of this bug in e2fsck except<br>
> changing i_dtime of inodes to current time?<br>
<br>
</div>Nope, that would be the only consequence --- if you don't the system<br>
administrator's anxiety that was induced by the false positive!<br></blockquote><div><br></div><div>Indeed it was no fun first couple of hours until I confirmed that data seem OK by comparing some of it to backup :)</div>
<div><br></div><div>From now on we will resize and fsck fs only with backup LVM snapshots. How much data is approximately overwritten / moved when resizing fs?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Thanks for pointing out this problem.  I'll make sure it gets fixed in<br>
the next maintenance release of e2fsprogs.<br>
<br>
                                        - Ted</blockquote><div> </div></div>Thanks for your prompt assistance.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Patrik</div></div>