Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: dump/restore out of range inode



> On 5. Jun 2021, at 12:31, Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:
> 
> On Sat, Jun 05, 2021 at 10:03:21AM -0000, Michael van Elst wrote:
>> prlw1%cam.ac.uk@localhost (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 is(gdb) print u_spcl.s_spcl
> 
> $2 = {c_type = 6, c_old_date = 0, c_old_ddate = 0, c_volume = 1,
>  c_old_tapea = 0, c_inumber = 397083647, c_magic = 424935705,
>  c_checksum = 1906085926, __c_ino = {__uc_dinode = {di_mode = 0,
>      di_nlink = 0, di_oldids = {0, 0}, di_size = 0, di_atime = 0,
>      di_atimensec = 0, di_mtime = 0, di_mtimensec = 0, di_ctime = 0,
>      di_ctimensec = 0, di_db = {0 <repeats 12 times>}, di_ib = {0, 0, 0},
>      di_flags = 0, di_blocks = 0, di_gen = 0, di_uid = 0, di_gid = 0,
>      di_modrev = 0}, __uc_ino = {__uc_mode = 0, __uc_spare1 = {0, 0, 0},
>      __uc_size = 0, __uc_old_atime = 0, __uc_atimensec = 0,
>      __uc_old_mtime = 0, __uc_mtimensec = 0, __uc_spare2 = {0, 0},
>      __uc_rdev = 0, __uc_birthtimensec = 0, __uc_birthtime = 0,
>      __uc_atime = 0, __uc_mtime = 0, __uc_spare4 = {0, 0, 0, 0, 0, 0, 0},
>      __uc_file_flags = 0, __uc_spare5 = {0, 0}, __uc_uid = 0, __uc_gid = 0,
>      __uc_spare6 = {0, 0}}}, c_count = 48473,
>  c_addr = '\000' <repeats 511 times>,
>  c_label = "none", '\000' <repeats 11 times>, c_level = 0,
>  c_filesys = "/store/backup", '\000' <repeats 50 times>,
>  c_dev = "/dev/rdk18", '\000' <repeats 53 times>,
>  c_host = "quantz", '\000' <repeats 57 times>, c_flags = 2,
>  c_old_firstrec = 0, c_date = 1622887657, c_ddate = 0, c_tapea = 10,
>  c_firstrec = 0, c_spare = {0 <repeats 24 times>}}
> (gdb) bt
> #0  flushtape () at /usr/src/sbin/dump/tape.c:333
> #1  0x000000000020763e in writerec (dp=dp@entry=0x7f7ff3a01380 "",
>    isspcl=isspcl@entry=0) at /usr/src/sbin/dump/tape.c:168
> #2  0x0000000000208e49 in dumpmap (map=<optimized out>, type=type@entry=6,
>    ino=ino@entry=397083647) at /usr/src/sbin/dump/traverse.c:716
> #3  0x000000000020b355 in main (argc=1, argv=0x7f7fffffe7e8)
>    at /usr/src/sbin/dump/main.c:646
> (gdb) list
> 328             }
> 329
> 330             blks = 0;
> 331             if (iswap32(spcl.c_type) != TS_END) {
> 332                     for (i = 0; i < iswap32(spcl.c_count); i++)
> 333                             if (spcl.c_addr[i] != 0)
> 334                                     blks++;
> 335             }
> 336             slp->count = lastspclrec + blks + 1 - iswap64(spcl.c_tapea);
> 337             slp->tapea = iswap64(spcl.c_tapea);
> (gdb) print i
> $6 = <optimized out>
> (gdb) print u_spcl.s_spcl.c_count
> $7 = 48473
> (gdb) whatis u_spcl.s_spcl.c_addr
> type = char [512]
> 
> so guess optimized_out i >> 512
> 
> c_type==6 = TS_CLRI map of inodes deleted since last dump
> 
> (a bit odd:
> (gdb) print needswap
> $11 = 0
> (gdb) print iswap32(u_spcl.s_spcl.c_count)
> $10 = 1505558528
> )
> 
> Still puzzled...

This trace makes no sense, bitmaps (CLRI and BITS) don't have holes
and therefore ignore the "c_addr" array.  I have no idea how dumping
a bitmap ends in the hole processing of flushtape().

--
J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig

Attachment: signature.asc
Description: Message signed with OpenPGP



Home | Main Index | Thread Index | Old Index