On Mon, Nov 01, 2021 at 01:23:48PM -0700, L A Walsh wrote: > > Addendum to the below: get_blocks showed no error messages. > > > When I xfsdump my /home partition, I see the above diagnostic > where it lists "bind mount?" might be involved, but as far as > I can see, that's not the case. Can you attach the full output for the xfs_dump and xfsrestore commands > > grepping for '/home\s' on output of mount: > > /bin/mount|grep -P '/home\s' > > shows only 1 entry -- nothing mounted on top of it: > > /dev/mapper/Space-Home2 on /home type xfs (...) > > I have bind-mounts of things like > /home/opt on /opt, but that shouldn't affect the root node, > as far as I know. > > So what would cause the root node to differ from the mountdir > ino? > > I try mounting the same filesystem someplace new: > > # df . > Filesystem Size Used Avail Use% Mounted on > /dev/Space/Home2 2.0T 1.5T 569G 73% /home > mkdir /home2 > Ishtar:home# mount /dev/Space/Home2 /home2 > Ishtar:home# ll -di /home /home2 > 256 drwxr-xr-x 40 4096 Nov 1 10:23 /home/ > 256 drwxr-xr-x 40 4096 Nov 1 10:23 /home2/ > > Shows 256 as the root inode. So why is xfsdump claiming > 192 is root inode? IIRC, it's because xfsdump thinks that the first inode in the filesystem is the root inode. Which is not always true - there are corner cases to do with stripe alignment, btree roots relocating and now sparse inodes that can result in new inodes being allocated at a lower number than the root inode. Indeed, the "bind mount?" message is an indication that xfsdump found that the first inode was not the same as the root inode, and so that's likely what has happened here. Now that I think about this, ISTR the above "inodes before root inode" situation being reported at some point in the past. Yeah: https://lore.kernel.org/linux-xfs/f66f26f7-5e29-80fc-206c-9a53cf4640fa@xxxxxxxxxx/ Eric, can you remember what came of those patches? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
