Hide Forgot
Created attachment 498753 [details] test tool to reproduce this issue
Compile the above attached test tool with: gcc -o tdb_expand_test -ltdb tdb_expand_test.c Using libtdb-1.2.1-5.el5: # time ./tdb_expand_test real 0m8.040s user 0m0.167s sys 0m0.930s # ls -l test.tdb -rw------- 1 root root 143933440 May 13 17:03 test.tdb Using libtdb-1.2.1-6.el5: # time ./tdb_expand_test real 0m2.268s user 0m0.055s sys 0m0.159s # ls -l test.tdb -rw------- 1 root root 15482880 May 13 17:04 test.tdb Verified in version: # rpm -qi libtdb Name : libtdb Relocations: (not relocatable) Version : 1.2.1 Vendor: Red Hat, Inc. Release : 6.el5 Build Date: Tue 12 Apr 2011 11:21:30 PM IST Install Date: Fri 13 May 2011 05:04:42 PM IST Build Host: x86-004.build.bos.redhat.com Group : System Environment/Daemons Source RPM: libtdb-1.2.1-6.el5.src.rpm Size : 56636 License: LGPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://tdb.samba.org/ Summary : The tdb library
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause The user runs fsck.gfs2 on a GFS2 file system in verbose mode (with the -v parameter). Consequence The user sees alarming error messages indicating that the master and root inode are not marked "In use" by the file system and an indication that the problem has been corrected: System inode for 'master' is located at block 23 (0x17) The inode exists but the block is not marked 'in use'; fixing it. System inode for 'root' is located at block 22 (0x16) The inode exists but the block is not marked 'in use'; fixing it. There is no problem with either inode; the error messages are just misleading. Fix The code has been changed to set both the master and root inodes as "in use" in the in-core block map. Result As a result, fsck.gfs2 now realizes the master and root inodes are properly marked, so the error messages are not printed.
(In reply to comment #5) > Technical note added. If any revisions are required, please edit the > "Technical Notes" field > accordingly. All revisions will be proofread by the Engineering Content > Services team. > > New Contents: > Cause > > The user runs fsck.gfs2 on a GFS2 file system in verbose mode (with the -v > parameter). > > Consequence > > The user sees alarming error messages indicating that the master and root inode > are not marked "In use" by the file system and an indication that the problem > has been corrected: > > System inode for 'master' is located at block 23 (0x17) > The inode exists but the block is not marked 'in use'; fixing it. > System inode for 'root' is located at block 22 (0x16) > The inode exists but the block is not marked 'in use'; fixing it. > > There is no problem with either inode; the error messages are just misleading. > > Fix > > The code has been changed to set both the master and root inodes as "in use" in > the in-core block map. > > Result > > As a result, fsck.gfs2 now realizes the master and root inodes are properly > marked, so the error messages are not printed. I suspect that you intended this message for a different bug.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,22 +1,13 @@ -Cause +This field is the basis of the errata or release note for this bug. It can also be used for change logs. -The user runs fsck.gfs2 on a GFS2 file system in verbose mode (with the -v parameter). +The Technical Note template, known as CCFR, is as follows: +Cause + What actions or circumstances cause this bug to present. Consequence - -The user sees alarming error messages indicating that the master and root inode are not marked "In use" by the file system and an indication that the problem has been corrected: - -System inode for 'master' is located at block 23 (0x17) -The inode exists but the block is not marked 'in use'; fixing it. -System inode for 'root' is located at block 22 (0x16) -The inode exists but the block is not marked 'in use'; fixing it. - -There is no problem with either inode; the error messages are just misleading. - + What happens when the bug presents. Fix - -The code has been changed to set both the master and root inodes as "in use" in the in-core block map. - + What was done to fix the bug. Result - + What now happens when the actions or circumstances above occur. -As a result, fsck.gfs2 now realizes the master and root inodes are properly marked, so the error messages are not printed.+ Note: this is not the same as the bug doesn’t present anymore.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -3,11 +3,13 @@ The Technical Note template, known as CCFR, is as follows: Cause - What actions or circumstances cause this bug to present. + A user account has been removed from a user group containing many members in LDAP. + Consequence - What happens when the bug presents. + The SSSD client software, while removing the user from the local cache, experiences an explosion of memory usage, likely resulting in the OOM killer being triggered. + Fix - What was done to fix the bug. + The SSSD's cache was corrected to properly clean up memory as it proceeded through the removal routines, thereby eliminating the memory explosion. + Result - What now happens when the actions or circumstances above occur. + The user is now properly removed from the user group in the cache without triggering the OOM killer.- Note: this is not the same as the bug doesn’t present anymore.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1050.html