[PATCH] xfsdump: fix metadata restore on split files

[Bill Kendall]

On 10/28/2011 04:37 AM, Christoph Hellwig wrote:
> On Wed, Oct 26, 2011 at 06:24:43PM -0500, Bill Kendall wrote:
>> xfsrestore does not apply certain metadata until all of the file's
>> data has been restored. This allows, for example, files with the
>> immutable flag set to be restored properly.
>>
>> While testing multi-stream restores, I noticed that files split
>> across multiple streams did not have their metadata restored.
>> Looking into this further, it also applies to the single-stream
>> case where files are split across media files, such as when a
>> backup spans multiple tapes.
>>
>> The fix is to check to see if a file is completely restored
>> whenever we hit the end of a media file. The current code
>> is broken because it relies on all media files being applied
>> during the same restore session.
>>
>> This also moves the S_ISREG() check into restore_complete_reg()
>> rather than relying on callers to make the check.
>
> Uhh, that's a nasty bug for people storing large files over multiple
> tapes.  Any chance we could get an xfstests test case for this?

I mischaracterized the existing bug, files split across tapes
are okay. The bug occurs when:

- a file ends right at the end of a tape in a multi-tape dump, and
- the next tape is not loaded during the same restore session
   (i.e., the restore is interrupted and resumed later)

> Can we somehow simulate multiple tapes using small files?

We can simulate multiple tapes on a single tape by asking for a
small media file size. I've got a couple of tests which do this
which I'll post later today.

I don't have a test for the exact scenario above. That would
require using 2 tapes (or 2 files on small loopback filesystems)
and knowing the exact number of bytes that will fit in the dump
file, then working backwards to find a file size that will end
at the right spot on media. Sounds like a very fragile test. It
would break if, for example, a file in the filesystem being
dumped was written as 2 extents instead of 1.

I'll repost this patch with correct commit message.

Bill