I'm not sure how all the moving parts here interact, but xfsdump does need to be pointed at the true root directory of a filesystem, not a bind-mounted directory below the root; it won't work properly otherwise.

i.e. if the "/" you are pointing at is actually a bind-mounted sub-directory of a parent filesystem, it's going to fail.  Is that the case?

See the command line under "Steps to reproduce"; the problem happens when the device is specified to xfsdump by the device name (e.g., "/dev/mapper/cl_hostname-root"), but not when specified by mount point (e.g., "/").

I'm guessing that xfsdump is trying to map the device name back to a mount point, and is getting the bind mount instead of the root.  I'm not sure what method xfsdump would use to try to do that mapping, but I note that /proc/mounts contains indistinguishable entries for each of the bind mounts in addition to the filesystem root, e.g.:

/dev/mapper/cl_hostname-root / xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
/dev/mapper/cl_hostname-root /var/named/chroot/etc/localtime xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
/dev/mapper/cl_hostname-root /var/named/chroot/etc/named.root.key xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
[...]
/dev/mapper/cl_hostname-root /var/named/chroot/var/named xfs rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0


If there's no better way for xfsdump to detect bind mounts, perhaps it could assume that entries for a device after the first one are bind mounts, and use the first match for the device in the mount table rather than the last one?  (I have no idea whether the order of entries in the mount table is deterministic.)

If running xfsdump on a device name without providing the filesystem root is not going to be supported, then at a minimum, Amanda would need to be updated not to map the mount point to a device when invoking xfsdump.

Oh, I see. Sorry for my confusion.

TBH, xfsdump is an ancient, tangled mess. You may be right that it's doing something odd when the device you've specified is found multiple times in /proc/mounts. I'll see what I can figure out.

It looks like fs_tab_lookup_blk() in xfsdump-3.1.8/common/fs.c returns the first result from the list constructed from fs_tab_ent_build() (which are the entries from /etc/mtab in reverse order) where the block device name matches or has the same st_rdev value.

Would it be practical for fs_tab_lookup_blk() to invoke (or duplicate the logic of) check_rootdir() from 0002-xfsdump-intercept-bind-mount-targets.patch to reject potential mount points that don't satisfy the root inode requirement?

Failing that, would changing fs_tab_lookup_blk() to return the last match from fs_tabp instead of the first one (i.e., declare
   fs_tab_ent_t *rtep = 0;
then change "return tep" to "rtep = tep" throughout, and change "return 0" to "return rtep" after the loop) be a practical workaround?  Again, this makes the assumption that bind mounts will always follow the real ones in /etc/mtab.

That assumption sounds pretty reasonable, but I always worry about coding to behavior that's not actually specified as a standard. I'll give this some thought, thanks.

In fact, I've found that the assumption does not necessarily hold, since it's technically possible to unmount and remount the underlying filesystem without removing the bind mount:

[djast@test djast]# mount --bind /boot/grub /mnt
[djast@test djast]# grep sda1 /etc/mtab
/dev/sda1 /boot xfs rw,relatime,attr2,inode64,noquota 0 0
/dev/sda1 /mnt xfs rw,relatime,attr2,inode64,noquota 0 0
[djast@test djast]# umount /boot
[djast@test djast]# mount /boot
[djast@test djast]# grep sda1 /etc/mtab
/dev/sda1 /mnt xfs rw,relatime,attr2,inode64,noquota 0 0
/dev/sda1 /boot xfs rw,relatime,attr2,inode64,noquota 0 0

Perhaps fs_tab_lookup_blk() should read /proc/self/mountinfo to identify and omit bind mounts of subdirectories, but a bind mount at the root would still be indistinguishable based on /proc/self/mountinfo.  However, that might be good enough for xfsdump's purposes--presumably the root inode would still be the same, so if one does "mount --bind / /mnt", would there be any difference between "xfsdump /" and "xfsdump /mnt"?

I know that xfsdump, unlike dump for ext2/3/4, requires that the filesystem be mounted in order to dump it (although I don't know why that restriction exists), but if a filesystem is mounted multiple times via bind mounts, does xfsdump need to know that in order to do its job, or is it sufficient for xfsdump to identify any suitable mount point?

(In reply to Dan Astoorian from comment #6)
> 
> I know that xfsdump, unlike dump for ext2/3/4, requires that the filesystem
> be mounted in order to dump it (although I don't know why that restriction
> exists), but if a filesystem is mounted multiple times via bind mounts, does
> xfsdump need to know that in order to do its job, or is it sufficient for
> xfsdump to identify any suitable mount point?

  I am interested in the answer to this question as we have also encountered
this issue.

  If the requirement exists that xfsdump _must_ use the mount point, then it 
perhaps the caller (in this case amanda) should be adjusted to use the mount 
point in place of the device in order to avoid the case where xfsdump is unable
to locate the root mount point automatically.

  The following single line change works for us as this section of code is 
already only applicable to xfsdump.

diff -uNrp amanda-3.5.1/client-src/sendbackup-dump.c amanda-3.5.1-p/client-src/sendbackup-dump.c
--- amanda-3.5.1/client-src/sendbackup-dump.c   2017-12-01 07:26:32.000000000 -0600
+++ amanda-3.5.1-p/client-src/sendbackup-dump.c 2022-05-13 10:37:50.029125898 -0500
@@ -308,7 +308,7 @@ start_backup(
                            "-F",
                            "-l", dumpkeys,
                            "-",
-                           device,
+                           dle->device,
                            NULL);
     }
     else

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.