Re: ./autorelabel

[mark]

Daniel J Walsh wrote:
>  On 07/19/2012 11:18 AM, m.roth(a)5-cent.us wrote:
> > Daniel J Walsh wrote:
> >> On 07/19/2012 11:03 AM, m.roth(a)5-cent.us wrote:
> >>>
> >>> I updated a CentOS system yesterday from 6.2 to 6.3. I saw it update
> >>> selinux-policy-targeted (I think it was) and several hours later, it
> >>> still hadn't gotten to the next package; looking, it appeared to be
> >>> running a restorecon. I killed it, and redid the update.
> >>>
> >>> For other reasons, it didn't reboot. I brought it up under the most
> >>> recent previous kernel, it did an fsck on a 2T drive... then it's been
> >>> running autorelabel for at least an hour and a half, and I have no
> >>> idea how much longer it will be. It's longer than fsck.
> >>>
> >>> This is a backup server, which uses hardlinks to save space.
> >>>
> >>> You may not consider this a bug, but it certainly makes selinux close
> >>> to unusable in anything resembling a working environment.
> >>>
> >> If you have a volume with a huge number of files on it, you could mount
> >> it with a context option and this will prevent restorecon from entering
> >> the volume for relabel.  Otherwise an autorelabel will attempt to read
> >> the context on ever file on the computer and "fix" it.
<snip>
> > But still, the fact that it takes that long is what I'm
> griping about.
> > If I'm doing an fsck -c, to check for bad blocks, I can understand why it
> > takes forever on 2T and 3T drives; but for this, where there are some
> > significantly smaller number of files than blocks, I still see that as a
> > problem.
>
>  Right when SELinux policy is updated it attempts to find the least
>  possible changes of labeling between the old labeling and the new labeling
>  (fixfiles -C filecontext.pre restore) In some cases this could get as 
high as
>  restorecon -R -v /usr or restorecon -R -v /var which seems to be what
you saw.

As a datapoint, it's now been relabelling for at least three or three and
a half hours. As I noted above, I believe that there are significantly
fewer files on this f/s than there are physical blocks that an fsck -c
would check. Therefore, I suggest to you that you folks need to revisit
your code, and look at speed optimizations.

        mark

./autorelabel

[thomas cameron]

On 07/19/2012 12:54 PM, m.roth(a)5-cent.us wrote:
>  Therefore, I suggest to you that you folks need to revisit
>  your code, and look at speed optimizations. 

Patches cheerfully accepted.

TC

./autorelabel

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/19/2012 01:54 PM, m.roth(a)5-cent.us wrote:
>  Daniel J Walsh wrote:
> > On 07/19/2012 11:18 AM, m.roth(a)5-cent.us wrote:
> >> Daniel J Walsh wrote:
> >>> On 07/19/2012 11:03 AM, m.roth(a)5-cent.us wrote:
> >>>> 
> >>>> I updated a CentOS system yesterday from 6.2 to 6.3. I saw it
> >>>> update selinux-policy-targeted (I think it was) and several hours
> >>>> later, it still hadn't gotten to the next package; looking, it
> >>>> appeared to be running a restorecon. I killed it, and redid the
> >>>> update.
> >>>> 
> >>>> For other reasons, it didn't reboot. I brought it up under the
> >>>> most recent previous kernel, it did an fsck on a 2T drive... then
> >>>> it's been running autorelabel for at least an hour and a half, and
> >>>> I have no idea how much longer it will be. It's longer than fsck.
> >>>> 
> >>>> This is a backup server, which uses hardlinks to save space.
> >>>> 
> >>>> You may not consider this a bug, but it certainly makes selinux
> >>>> close to unusable in anything resembling a working environment.
> >>>> 
> >>> If you have a volume with a huge number of files on it, you could
> >>> mount it with a context option and this will prevent restorecon from
> >>> entering the volume for relabel.  Otherwise an autorelabel will
> >>> attempt to read the context on ever file on the computer and "fix"
> >>> it.
>  <snip>
> >> But still, the fact that it takes that long is what I'm griping about. 
> >> If I'm doing an fsck -c, to check for bad blocks, I can understand why
> >> it takes forever on 2T and 3T drives; but for this, where there are
> >> some significantly smaller number of files than blocks, I still see
> >> that as a problem.
> > 
> > Right when SELinux policy is updated it attempts to find the least 
> > possible changes of labeling between the old labeling and the new
> > labeling (fixfiles -C filecontext.pre restore) In some cases this could
> > get as
>  high as
> > restorecon -R -v /usr or restorecon -R -v /var which seems to be what
>  you saw.
>  
>  As a datapoint, it's now been relabelling for at least three or three and a
>  half hours. As I noted above, I believe that there are significantly fewer
>  files on this f/s than there are physical blocks that an fsck -c would
>  check. Therefore, I suggest to you that you folks need to revisit your
>  code, and look at speed optimizations.
>  
>  mark
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
THis code has been heavily optimized over the years, I have no heard of
something this slow, so maybe there is a bug being triggered.  Does find /
take a huge amount of time on this machine?

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlAJvv4ACgkQrlYvE4MpobMSlACgtuBnRDUD8fjooPVArXInW7H4
> ezgAoKvKXs8OMpK+eXhTqxF+6NdOdLeL
> =3tpu
> -----END PGP SIGNATURE-----