-----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-----