Description of problem: If updatedb scans a GFS filesystem it causes performance to slow drastically due to lock contention problems. Version-Release number of selected component (if applicable): Any How reproducible: Always Steps to Reproduce: 1. Run updatedb on a GFS filesystem 2. Do a lot of "df" and "ls" commands on the gfs filesystem 3. Actual results: Eventually df and ls will start to hang/go extremely slow Expected results: df and ls should return as normal Solution: Add "gfs" and "gfs2" to the PRUNEFS list in /etc/updatedb.conf Additional info:
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
This bug seems to have been forgotten. Bringing it up to the latest RHEL version. I know we've missed 5.3, so lets aim for 5.4.
Hmm, just found the bug for 5.4 as well. So we don't need this one then I think. *** This bug has been marked as a duplicate of bug 221547 ***
This was originally filed against RHEL4, so closing as a duplicate of a RHEL5 bug would lose the RHEL4 bug. Reopening - if you don't care about RHEL4 any more, please say so explicitly.
There is no point in adding gfs2 to the list in RHEL4, because gfs2 does not (and will not) ever be a part of RHEL4. Since this bug has been open for two years with apparently no progress even though its a trivial change, I'd rather given up hope of it happening. Is there a reason that its taken so long? Can we speed this process up somehow?
(In reply to comment #5) > There is no point in adding gfs2 to the list in RHEL4, because gfs2 does not > (and will not) ever be a part of RHEL4. Thanks, closing this. > Since this bug has been open for two > years with apparently no progress even though its a trivial change, I'd rather > given up hope of it happening. Is there a reason that its taken so long? Can we > speed this process up somehow? One reason is that I don't want to release this default configuration change as a fastrack update (to at least give the users a chance to read about it in release notes); there was at least one fastrack mlocate update since filing the bugs. I'm afraid it seems this very small update is not - or seems not to be - that important when compared to other possible package updates in a RHEL update release.