On 5/15/19 3:47 PM, Omar Sandoval wrote: > Hi, > > We use xfsdump and xfsrestore (v3.1.7) to back up one of our storage > systems, and we ran into an issue where xfsdump prints the following for > a mount which isn't a bind mount: > > /sbin/xfsdump: NOTE: root ino 136 differs from mount dir ino 256, bind mount? > > Which also results in a crash from xfsrestore: > > xfsrestore: tree.c:757: tree_begindir: Assertion `ino != persp->p_rootino || hardh == persp->p_rooth' failed. > > Looking at [1], xfsdump uses bulkstat to get the minimum inode number on > the filesystem. But, at least one of our filesystems has a root inode > number of 256 and uses inode numbers 136-199, which tricks xfsdump into > thinking that the filesystem is bind mounted. Is this an invalid > assumption in xfsdump, or is it filesystem corruption? > > Thanks! > > 1: https://git.kernel.org/pub/scm/fs/xfs/xfsdump-dev.git/commit/?id=25195ebf107dc81b1b7cea1476764950e1d6cc9d Yep, this is that heuristic going wrong. We (I) didn't realize that we could ever get inode numbers allocated which were less than the root inode, but alas. It's an invalid assumption in xfsdump. I guess we need to find a way out of this ... the goal was to detect bind mounts, but apparently the situation you have is more common than expected (well, we expected it to not exist ...) For now just using an older version of xfsdump should be a workaround, sorry about that. -Eric
