-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/19/2012 01:54 PM, m.roth@xxxxxxxxx wrote: > Daniel J Walsh wrote: >> On 07/19/2012 11:18 AM, m.roth@xxxxxxxxx wrote: >>> Daniel J Walsh wrote: >>>> On 07/19/2012 11:03 AM, m.roth@xxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx > 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----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
