Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Mar 2009 12:19:31 -0400
From:      "Mikhail T." <mi+thun@aldan.algebra.com>
To:        Danny Braniss <danny@cs.huji.ac.il>
Cc:        Daniel O'Connor <doconnor@gsoft.com.au>, freebsd-stable@freebsd.org, fs@freebsd.org
Subject:   Re: dump | restore fails: unknown tape header type 1853384566
Message-ID:  <49C90813.8070705@aldan.algebra.com>
In-Reply-To: <E1Lm1J9-000Ah6-Kf@kabab.cs.huji.ac.il>
References:  <49C83673.3000604@aldan.algebra.com> <200903241537.36515.doconnor@gsoft.com.au> <49C87E0D.5090501@aldan.algebra.com> <E1Lm1J9-000Ah6-Kf@kabab.cs.huji.ac.il>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49C90813.8070705>