Re: Many orphaned inodes after resize2fs

--===============0264549724408116018==
Content-Type: multipart/alternative; boundary=047d7bacbaaa1c488704f7681d3a

--047d7bacbaaa1c488704f7681d3a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2014-04-19 17:48 GMT+02:00 Theodore Ts'o <[email protected]>:

> On Sat, Apr 19, 2014 at 05:42:12PM +0200, Patrik Horn=EDk wrote:
> >
> > Please confirm that this is fully correct solution (for my purpose, not
> > elegant clean way for official fix) and it has no negative consequences=
.
> It
> > seems that way but I did not analyze all code paths the fixed code is i=
n.
>
> Yes, that's a fine solution.  What I'll probably do is disable the
> check if s_inodes_count is greater than s_mkfs_time minus some fudge
> value, or if the broken system clock boolean is set.
>
> > BTW were there any other negative consequences of this bug in e2fsck
> except
> > changing i_dtime of inodes to current time?
>
> Nope, that would be the only consequence --- if you don't the system
> administrator's anxiety that was induced by the false positive!
>

Indeed it was no fun first couple of hours until I confirmed that data seem
OK by comparing some of it to backup :)

>From now on we will resize and fsck fs only with backup LVM snapshots. How
much data is approximately overwritten / moved when resizing fs?


> Thanks for pointing out this problem.  I'll make sure it gets fixed in
> the next maintenance release of e2fsprogs.
>
>                                         - Ted


Thanks for your prompt assistance.

Patrik

--047d7bacbaaa1c488704f7681d3a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2014=
-04-19 17:48 GMT+02:00 Theodore Ts&#39;o <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span>:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<div class=3D"">On Sat, Apr 19, 2014 at 05:42:12PM +0200, Patrik Horn=EDk w=
rote:<br>
&gt;<br>
&gt; Please confirm that this is fully correct solution (for my purpose, no=
t<br>
&gt; elegant clean way for official fix) and it has no negative consequence=
s. It<br>
&gt; seems that way but I did not analyze all code paths the fixed code is =
in.<br>
<br>
</div>Yes, that&#39;s a fine solution. =A0What I&#39;ll probably do is disa=
ble 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=3D""><br>
&gt; BTW were there any other negative consequences of this bug in e2fsck e=
xcept<br>
&gt; changing i_dtime of inodes to current time?<br>
<br>
</div>Nope, that would be the only consequence --- if you don&#39;t the sys=
tem<br>
administrator&#39;s anxiety that was induced by the false positive!<br></bl=
ockquote><div><br></div><div>Indeed it was no fun first couple of hours unt=
il 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 res=
izing fs?</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Thanks for pointing out this problem. =A0I&#39;ll make sure it gets fixed i=
n<br>
the next maintenance release of e2fsprogs.<br>
<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 - Ted</blockquote><div>=A0</div></div>Thanks for your prompt assistanc=
e.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Pat=
rik</div></div>

--047d7bacbaaa1c488704f7681d3a--


--===============0264549724408116018==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ext3-users mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/ext3-users
--===============0264549724408116018==--