Re: [PATCH 0/9] xfs-5.0: inode scrubber fixes

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Wed, Dec 19, 2018 at 06:45:26PM +0530, Chandan Rajendra wrote:
> On Wednesday, December 19, 2018 2:01:13 PM IST Chandan Rajendra wrote:
> > On Thursday, November 29, 2018 4:56:58 AM IST Darrick J. Wong wrote:
> > > Hi all,
> > > 
> > > Here are fixes for some problems with the inode btree scrub code, namely
> > > that the existing code does not handle the case where a single inode
> > > cluster is mapped by multiple inobt records.
> > > 
> > > Patch 1 teaches the inode record block counting code to handle the case
> > > where there's more than one inobt record per inode cluster.  We do this
> > > by counting inodes and converting to blocks only at the end.
> > > 
> > > Patch 2 corrects a condition where we needed to clamp the number of
> > > inodes checked for a given inobt record to the inode chunk size.
> > > 
> > > Patches 3-4 move the inobt record alignment checks to a separate
> > > function and enhance the function to check that when we have more than
> > > one inobt record per cluster we actually check that *all* of the
> > > necessary records are present and in the correct order.
> > > 
> > > Patches 5-7 reorganize the inobt free data checks to deal with the
> > > "multiple inobt records per icluster" situation.  In restructuring the
> > > code to do so, we also rename variables and functions to be less
> > > confusing about what they're there for.  We also fix the 'is the inode
> > > free?' check to calculate dinode buffer offsets correctly in the
> > > "multiple inobt records per icluster" situation.
> > > 
> > > Patch 8 aborts the xattr scrub loop if there are pending fatal signals.
> > > 
> > > Patch 9 checks that for any directory or attr fork there are no extent
> > > maps that stretch beyond what a xfs_dablk_t can map.
> > > 
> > > If you're going to start using this mess, you probably ought to just
> > > pull from my git trees.  The kernel patches[1] should apply against
> > > 4.20-rc4.
> > > 
> > > Comments and questions are, as always, welcome.
> > 
> > Hi Darrick,
> > 
> > I reviewed patches 1 through 7. The fixes look good.
> > 
> > I am not well versed with the XFS code that deals with xattrs &
> > directories. Hence I could not review patches 8 and 9.
> > 
> > I did a simple scrub test on a 64k blocksized filesystem running a kernel
> > having the following commit as the HEAD,
> > 
> > commit 6c4e1579b332e52566c11416e0dd0fa91a3b8f70 (HEAD -> djwong-devel, djwong-xfs-linux/djwong-devel)
> > Author: Darrick J. Wong <darrick.wong@oracle.com>
> > Date:   Thu Oct 18 17:35:49 2018 -0700
> > 
> >     xfs: repair quotas
> >     
> >     Fix anything that causes the quota verifiers to fail.
> >     
> >     Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > 
> > Xfsprogs had the following as the topmost commit,
> > 
> > commit 633eec2a893c3be9796dad188144b00e084560ec (HEAD -> djwong-devel, djwong/djwong-devel)
> > Author: Darrick J. Wong <darrick.wong@oracle.com>
> > Date:   Tue Nov 13 17:38:31 2018 -0800
> > 
> >     xfs: repair extended attributes
> >     
> >     If the extended attributes look bad, try to sift through the rubble to
> >     find whatever keys/values we can, zap the attr tree, and re-add the
> >     values.
> >     
> >     Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > 
> > 
> > The test filesystem had 2000 files with each being 64k in size.
> > 
> > root@ubuntu:~# xfs_scrub -d -n -v /mnt/
> > EXPERIMENTAL xfs_scrub program in use! Use at your own risk!
> > Phase 1: Find filesystem geometry.
> > /mnt/: using 8 threads to scrub.
> > Phase 2: Check internal metadata.
> > Info: AG 1 superblock: Optimization is possible. (scrub.c line 269)
> > Info: AG 3 superblock: Optimization is possible. (scrub.c line 269)
> > Info: AG 2 superblock: Optimization is possible. (scrub.c line 269)
> > Error: AG 0 free inode btree: Repairs are required. (scrub.c line 253)
> > Phase 3: Scan all inodes.
> > Phase 5: Check directory tree.
> > Info: /mnt/: Filesystem has errors, skipping connectivity checks. (phase5.c line 295)
> > Phase 7: Check summary counters.
> > 163.9MiB data used;  1.9K inodes used.
> > 152.7MiB data found; 1.9K inodes found.
> > 1.9K inodes counted; 1.9K inodes checked.
> > /mnt/: errors found: 1
> > /mnt/: Re-run xfs_scrub without -n.
> > 
> > Looks like we have a bug when scrubbing the Free inode btree. I will work on
> > figuring out the root cause and also plan to execute scrub tests shipped with
> > xfstests.
> > 
> > 
> 
> We do have an unaligned finobt record,
> 
> xfs_scrub 27247 [004] 18014.774762: probe:xchk_iallocbt_rec_alignment: (c00000000075941c) ir_startino=176960 ig_cluster_align_inodes=128 imask_u32=127
>         c00000000075941c xchk_iallocbt_rec_alignment+0x10c (/boot/vmlinux)
>         c00000000075966c xchk_iallocbt_rec+0x14c (/boot/vmlinux)
>                        0 [unknown] ([unknown])
>         c000000000752968 xchk_btree+0x288 (/boot/vmlinux)
>         c0000000007598c4 xchk_iallocbt+0x64 (/boot/vmlinux)
>         c00000000075dc1c xfs_scrub_metadata+0x4ac (/boot/vmlinux)
>         c0000000006e4b88 xfs_ioc_scrub_metadata+0x68 (/boot/vmlinux)
>         c0000000006e7d5c xfs_file_ioctl+0xbbc (/boot/vmlinux)
>         c000000000425e04 do_vfs_ioctl+0xd4 (/boot/vmlinux)
>         c000000000426874 ksys_ioctl+0x64 (/boot/vmlinux)
>         c000000000426928 __se_sys_ioctl+0x28 (/boot/vmlinux)
>         c00000000000bae4 system_call+0x5c (/boot/vmlinux)
>             7ffff77d7694 __GI___ioctl+0x114 (/lib/powerpc64le-linux-gnu/libc-2.27.so)
>                10000e4e0 xfs_check_metadata+0x100 (/root/repos/xfsprogs-dev/scrub/xfs_scrub)
>                10000e484 xfs_check_metadata+0xa4 (/root/repos/xfsprogs-dev/scrub/xfs_scrub)
>                10000ec48 xfs_scrub_metadata+0xd8 (/root/repos/xfsprogs-dev/scrub/xfs_scrub)
>                100008dac xfs_scan_ag_metadata+0x12c (/root/repos/xfsprogs-dev/scrub/xfs_scrub)
>                1000198c8 workqueue_thread+0x108 (/root/repos/xfsprogs-dev/scrub/xfs_scrub)
>             7ffff7f2885c start_thread+0x10c (/lib/powerpc64le-linux-gnu/libpthread-2.27.so)
>             7ffff77e9028 __clone+0x98 (/lib/powerpc64le-linux-gnu/libc-2.27.so)
> 
> Maybe this is due to a bug in the finobt code. I will continue debugging and
> report my findings.

Ok.  Feel free to send along a metadump if you have one.

--D

> -- 
> chandan
> 
> 
>