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@xxxxxxxxxx> > > 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@xxxxxxxxxx> > > > > > > Xfsprogs had the following as the topmost commit, > > > > commit 633eec2a893c3be9796dad188144b00e084560ec (HEAD -> djwong-devel, djwong/djwong-devel) > > Author: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > 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@xxxxxxxxxx> > > > > > > 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 > > >
