Bug 1717513

Created attachment 1577642 [details]
Checker script

I wrote this tiny script to compare the values of the formal inode
number in the directory entry versus the dinode. Example usage:

Parameters are: <device> <path from that device>

Run it on a known good file:

# /home/bob/tools/check_formal_ino.sh /dev/fsck/case02236799files /fecho/ioc_mestre/gis/eb_docs_02_gfg.sas7bdat
fecho  -> 		 0x3b3ed9d
ioc_mestre  -> 		 0x3b3eda2
gis  -> 		 0x3b40fe4
eb_docs_02_gfg.sas7bdat  -> 		 0x3b50e7c

Dinode: 0x344
Dirent: 0x344

Notice that the dinode agrees with the dirent that the formal inode
number is 0x344. Now run it on a known bad file:

# /home/bob/tools/check_formal_ino.sh /dev/fsck/case02236799files /fecho/ioc_mestre/gis_erro_sistema/eb_docs_02_gfg.sas7bdat
fecho  -> 		 0x3b3ed9d
ioc_mestre  -> 		 0x3b3eda2
gis_erro_sistema  -> 		 0x3b589b7
eb_docs_02_gfg.sas7bdat  -> 		 0x464011c

Dinode: 0x1f4d1
Dirent: 0x1f54b

Test case:

#!/bin/bash

DEV=/dev/foo
MNT=/mnt/test

mkfs.gfs2 -O -p lock_nolock $DEV
mount $DEV $MNT
touch $MNT/foo
INODE=$(ls -i $MNT/foo | cut -f1 -d' ')
umount $MNT
gfs2_edit -p $INODE field di_num.no_formal_ino 42 $DEV
fsck.gfs2 -y $DEV
if [ $? -ne 1 ]; then
	echo "FAIL: fsck.gfs2 did not find and fix the bad dentry" >&2
	exit 1
fi
fsck.gfs2 -n $DEV
if [ $? -ne 0 ]; then
	echo "FAIL: fsck.gfs2 found problems, fs should be clean" >&2
	exit 1
fi

Should this bug be closed or moved to RHEL8?

Doesn't look like anyone has been working on this for 2 years, single case is closed.

Should this be a CLOSE or what is expected?

Sorry, didn't mean to close until owner and reporter agree on next steps.

I would like to keep this one open to track the remaining work. It's blocked behind the general fsck.gfs2 performance work (which itself is blocked at the moment) so it will likely take some time.

(In reply to Andrew Price from comment #21)
> I would like to keep this one open to track the remaining work. It's blocked
> behind the general fsck.gfs2 performance work (which itself is blocked at
> the moment) so it will likely take some time.

Is this still in the works?  Can you give an update on it, and maybe add in depends on bugs as needed?

(In reply to Dave Wysochanski from comment #23)
> Is this still in the works?  Can you give an update on it, and maybe add in
> depends on bugs as needed?

Yes this still needs to be addressed and it's currently sitting on the backlog. Some groundwork for the general performance issues went into gfs2-utils 3.5.0 but we still need to find a way to implement the formal_ino check without the considerable performance hit so the "Cond NAK: Design" is still valid. A depends on 1721973 is already set so I think the bz state is up-to-date.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.