On Wed, May 15, 2019 at 03:51:07PM -0500, Eric Sandeen wrote: > 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 Great, thanks for the confirmation!
