On 8/20/17 8:26 PM, ToddAndMargo wrote:

On 08/20/2017 10:59 AM, Eric Sandeen wrote:

quoted

On 8/20/17 12:57 AM, ToddAndMargo wrote:

quoted

Dear Xfs,

Do I report this to you or Red Hat?

Fedora Core 26, x564

Here is fine, or Fedora if you want, but it'll be the same people responding in any case.

quoted

xfsdump-3.1.6-4.fc26.x86_64

When I run the following

     # /sbin/xfsdump -v verbose -M 1 -L 1 -l 0 -f /lin-bak/2017-08-19_22-30-27_md126p2.XfsDump  /

randomly, I get this error message when I run xfsdump:


     /sbin/xfsdump: ino map phase 1: constructing initial dump list
     /sbin/xfsdump: WARNING: failed to get bulkstat information for inode 739
     /sbin/xfsdump: WARNING: failed to get bulkstat information for inode 954
     /sbin/xfsdump: WARNING: failed to get bulkstat information for inode 1118
     about 40 more of them

And the next time it will run clean.  What gives?

Most likely it's files that got deleted while xfsdump was running.  xfsdump has a bad habit of issuing warnings for things that are not actually problematic.

But you could also look for those inodes on the filesystem you're dumping; what are they?  Are they still there, or were they transient files?

If you quiesce the filesystem first, or dump from a snapshot, you should not see such errors.

-Eric

quoted

I put a `sunc; sync` before the dump command and it seems to help, but it is random, so who knows.

Is this a bug?  Or am I doing something wrong?

Many thanks,
-T

Hi Eric,

Thank you for responding!

After I added `sync; sync` before the call to xfsdump, I ran
about 10 more backups without a hitch.

I also run xfsdump at my office.  It does complain about missing
stuff if I leave Thunderbird running during the backup.
But it is the occasional single error.  Not a broken fire hydrant
of millions of errors.

My office version is xfsdump-3.1.4-1.el7.x86_64  (Scientific
Linux, a.k.a. "old-out-of-date").

As a test, I ssh logged into the server question while writing
this, it having been running overnight, and ran the sync
modified dump again.  The problem did not reproduce.

The difference between my office and the customer is
that I use a hardware raid (raid 1) card and the customer
uses RSTe ("e" for enterprise) RAID 1, which is a pseudo
software raid.  Maybe a lot of stuff is floating around
in the either (cache) that is not sync'ed to the drive pair
and xfsdump is not happy about it.

The underlying storage will not affect this.

I am wonder if it would be possible for xfsdump to can
"sync; sync" itself before starting.  That would insure
a clean slate.

No; that's a guess, not a root cause analysis - we won't
be putting hacks like that in based on hunches.

If you want to investigate more, find out where in the code
the error spits out, and do more error reporting there; find out
what error code is actually being returned.  actually I suppose
strace would work for this as well.  Knowing which error code
the ioctl fails with would offer a clue about why.

-Eric

-T