dump | restore fails: unknown tape header type 1853384566

[Mikhail T.]

Danny Braniss написав(ла):
>> Daniel O'Connor написав(ла):
>>
>> On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
>>
>>   
>>     
>>>> I'm trying to migrate a filesystem from one disk to another using:
>>>>
>>>>     dump a0hCf 0 32 - /old | restore -rf -
>>>>
>>>> (/old is already mounted read-only). The process runs for a while and> >> then stops with:
>>>>
>>>>     [...]
>>>>       DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
>>>>       DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
>>>>       DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
>>>>     unknown tape header type 1853384566> >>     abort? [yn]
>>>>
>>>> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
>>>> dump's output?
>>>>     
>>>>
>>>>         
>  > What happens if you don't use the cache?
>   
>>>   
>>>       
>> No big difference:
>>     
>>>     dump a0f  - /old | restore -rf -
>>>       
>>     [...]
>>       DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>>       DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>>       DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>>     unknown tape header type -621260722>     abort? [yn]
>>
>> Looks like a junk value somewhere... Unitialized variable or some such.
>>
>>     
> can you try splitting it in 2, ie no pipe?
> 	dump a0f some.file /old (or dump 0f - /old | gzip -c > file.dump.gz)
> 	restore rf some.file
>
> danny
>   
Well, the first part (the dump) runs almost to the completion, but hangs 
at the very end for some reason:

    dump 0aCf 64  /ibm/ibmo.0.2009-03-24.dump /old
      DUMP: WARNING: should use -L when dumping live read-write filesystems!
      DUMP: Date of this level 0 dump: Tue Mar 24 05:59:27 2009
      DUMP: Date of last level 0 dump: the epoch
      DUMP: Dumping /dev/ad2s1e (/ibmo) to /ibm/ibmo.0.2009-03-24.dump
      DUMP: mapping (Pass I) [regular files]
      DUMP: Cache 64 MB, blocksize = 65536
      DUMP: mapping (Pass II) [directories]
      DUMP: estimated 152357442 tape blocks.
      DUMP: dumping (Pass III) [directories]
      DUMP: dumping (Pass IV) [regular files]
      DUMP: 0.83% done, finished in 9:59 at Tue Mar 24 16:04:19 2009
      DUMP: 2.74% done, finished in 5:55 at Tue Mar 24 12:05:07 2009
      DUMP: 4.66% done, finished in 5:06 at Tue Mar 24 11:21:27 2009
      DUMP: 6.58% done, finished in 4:43 at Tue Mar 24 11:03:37 2009
    ...
      DUMP: 91.54% done, finished in 0:23 at Tue Mar 24 10:38:15 2009
      DUMP: 93.41% done, finished in 0:18 at Tue Mar 24 10:38:02 2009
      DUMP: 95.27% done, finished in 0:13 at Tue Mar 24 10:37:50 2009
      DUMP: 97.15% done, finished in 0:07 at Tue Mar 24 10:37:36 2009
      DUMP: 99.03% done, finished in 0:02 at Tue Mar 24 10:37:23 2009
      DUMP: DUMP: 152769349 tape blocks on 1 volume
      DUMP: finished in 16706 seconds, throughput 9144 KBytes/sec
    [... Hang ...]
    load: 0.18  cmd: dump 10105 [sbwait] 72.53u 383.14s 0% 73048k
    load: 0.19  cmd: dump 10102 [sbwait] 164.93u 314.87s 0% 75008k
    load: 0.10  cmd: dump 10102 [running] 164.93u 314.87s 0% 75008k

The timestamp on the output file is, indeed, 10:38 and the dumping 
process is hanging ever since then (over 90 minutes already).

Yours,

    -mi