On 11/28/16 3:21 AM, Dave Chinner wrote: > I think you misunderstand how the inventory and dump process > works. The dump process first builds the inventory inode map that it > needs to back up, then goes and backs up what it mapped in the > inventory. The filesystem can change between the inventory build > an dump trying to backup the file, and if the file does not match > the inventory for some reason (e.g. different inode generation > number) it will skip it. The file does not get removed from the > inventory, though, because that's already been written to the dump > file. > > There have also been situations where kernel bugs have meant xfsdump > missed files. e.g. off-by-ones in bulkstat continuation code. These > bugs had identical symptoms to what you are reporting, but given a > new dump worked this is probably not the issue.... Another possible scenario that I'm wondering whether it's plausible: My XFS filesystem was mildly corrupted (e.g. because of power failure or other trouble). But not in a way that was checked/noticed/corrected automatically on system boot, or even had a noticeable effect on the system other than the missing file on xfsrestore? The system is back up and running, seemingly-fine. But perhaps obviously, my main concern here is to avoid this kind of scenario in the future. e.g., is there something I'm missing in my backup routine? Silent failures on backup/restore are not very reassuring. Thanks! -WD -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
