> On 6. Jun 2021, at 10:10, Patrick Welche wrote:
>
> On Sat, Jun 05, 2021 at 06:45:24PM +0200, J. Hannken-Illjes wrote:
>> Patrick,
>>
>> please try the attached diff so the "spcl.c_addr" test
>> no longer runs off the spcl record.
>>
>> "blks" is used for multi-tape checkpointing and
On Sat, Jun 05, 2021 at 06:45:24PM +0200, J. Hannken-Illjes wrote:
> Patrick,
>
> please try the attached diff so the "spcl.c_addr" test
> no longer runs off the spcl record.
>
> "blks" is used for multi-tape checkpointing and examining
> TS_INODE/TS_ADDR records should be sufficient as the are
Patrick,
please try the attached diff so the "spcl.c_addr" test
no longer runs off the spcl record.
"blks" is used for multi-tape checkpointing and examining
TS_INODE/TS_ADDR records should be sufficient as the are
the only records that support holes in data.
--
J. Hannken-Illjes -
> On 5. Jun 2021, at 12:31, Patrick Welche wrote:
>
> On Sat, Jun 05, 2021 at 10:03:21AM -, Michael van Elst wrote:
>> pr...@cam.ac.uk (Patrick Welche) writes:
>>
>>> How can gdb not see a spcl anywhere?
>>
>> /usr/include/protocols/dumprestore.h:#define spcl u_spcl.s_spcl
>>
>> spcl is
On Sat, Jun 05, 2021 at 10:03:21AM -, Michael van Elst wrote:
> pr...@cam.ac.uk (Patrick Welche) writes:
>
> >How can gdb not see a spcl anywhere?
>
> /usr/include/protocols/dumprestore.h:#define spcl u_spcl.s_spcl
>
> spcl is just a define that got resolved by the compiler.
ach... here it
pr...@cam.ac.uk (Patrick Welche) writes:
>How can gdb not see a spcl anywhere?
/usr/include/protocols/dumprestore.h:#define spcl u_spcl.s_spcl
spcl is just a define that got resolved by the compiler.
On Thu, Jun 03, 2021 at 05:14:07PM -, Michael van Elst wrote:
> pr...@cam.ac.uk (Patrick Welche) writes:
>
> > DUMP: Child 29322 returns LOB status 213
> >213=0xd5
>
> That's octal. Return status 0213 = 139 -> WCOREFLAG(==128) + signal 11.
>
> >Can this happen if the original filesystem is
pr...@cam.ac.uk (Patrick Welche) writes:
> DUMP: Child 29322 returns LOB status 213
>213=0xd5
That's octal. Return status 0213 = 139 -> WCOREFLAG(==128) + signal 11.
>Can this happen if the original filesystem is broken? At a distance
>it just looks as though restore hasn't read a symbol table
On a 9.99.83/amd64 box, I just observed the following:
# mount -r -o noatime NAME=backup /store/backup
# cd /tmp/foo
# dump -0auf - /store/backup | /sbin/restore vdrf -
Verify tape and initialize maps
