Hide Forgot
Description of problem: The gfs2_edit savemeta feature does not save leaf chain blocks. These are cases where a dinode's leaf block points to another "chain" leaf block via lf_next. We need to fix gfs2_edit so that it saves all leaf chain blocks. Version-Release number of selected component (if applicable): All How reproducible: Always Steps to Reproduce: Something like this: mkfs.gfs2 -O -j1 -plock_nolock /dev/sasdrives/scratch |grep "groups" mount -tgfs2 /dev/sasdrives/scratch /mnt/gfs2 cd /mnt/gfs2 /home/bob/tools/bz1138749_tests/100_names.sh cd - umount /mnt/gfs2 gfs2_edit savemeta /dev/sasdrives/scratch /tmp/100names.with.same.hash.meta.gz gfs2_edit -p 0x8349 /dev/sasdrives/scratch |grep lf_next gfs2_edit printsavedmeta /tmp/100names.with.same.hash.meta.gz |grep 0x8349 gfs2_edit printsavedmeta /tmp/100names.with.same.hash.meta.gz |grep 0x834a Actual results: Block 0x834a does not appear in the printsavedmeta output because it was never saved. That's the problem. Expected results: 33644 (l=0xff8): Block #33610 (0x834a) (directory leaf) Additional info: The steps given above do this: 1. A new GFS2 file system is made and mounted 2. The script creates enough files with a duplicate hash value that the leaf block is forced into a chain leaf block. In this case, block 0x834a is the chain leaf block. 3. The file system is unmounted and the metadata saved to a file. 4. The leaf block at 0x8349 is printed to prove we have a non-zero value for lf_next. 5. The first printsavedmeta proves we saved that leaf which has the forward chain. 6. The second printsavedmeta proves gfs2_edit savemeta did or did not save the chain leaf block.
Created attachment 1207653 [details] Script used to recreate the problem Ben Marzinski created this script to touch one hundred files that all have the same hash value, which forces GFS2 to put some of them on a leaf chain block.
This should be easy to fix. Setting devel_ack flag for 7.4
The fix for this has gone upstream <https://git.fedorahosted.org/cgit/gfs2-utils.git/commit/?id=b4333e4109d0> so it will be pulled in when gfs2-utils is rebased.
Verified in gfs2-utils-3.1.10-3.el7: [root@host-008 ~]# rpm -q gfs2-utils gfs2-utils-3.1.10-3.el7.x86_64 [root@host-008 ~]# mkfs.gfs2 -O -j1 -plock_nolock /dev/sda |grep "groups" Building resource groups: Done Resource groups: 801 [root@host-008 ~]# mount -tgfs2 /dev/sda /mnt/gfs2 [root@host-008 ~]# cd /mnt/gfs2 [root@host-008 gfs2]# /root/100_names.sh [root@host-008 gfs2]# cd - /root [root@host-008 ~]# umount /mnt/gfs2 [root@host-008 ~]# gfs2_edit savemeta /dev/sda 100names.with.same.hash.meta.gz There are 52428798 blocks of 4096 bytes in the filesystem. Filesystem size: 199.1023GB 52428798 blocks processed, 37876 saved (100%) Metadata saved to file 100names.with.same.hash.meta.gz (gzipped, level 9). [root@host-008 ~]# gfs2_edit -p root /dev/sda |grep Dir Directory block: lf_depth:17, lf_entries:83, lf_inode: 0x8178, lf_dist: 1, lf_nsec: 10215949, lf_sec: 1495588000, fmt:1200 next=0x83ad (83 dirents). [root@host-008 ~]# gfs2_edit printsavedmeta 100names.with.same.hash.meta.gz |grep 0x83ad 33663 (l=0x398): Block #33709 (0x83ad) (directory leaf)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2226