Re: Core Dump Panic String: assertion: cursor->flags & HAMMER_CURSOR_ITERATE_CHECK in hammer_btree_iterate

[Siju George <sgeorge.ml@xxxxxxxxx>]

On Wed, Apr 28, 2010 at 11:40 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>
>    Oh my.  That is a case which we've never tested.
>
>    What I would do is test the 'latest' snapshot available on the slave
>    to see if everything is accessible.  Doing a dummy tar of it ought
>    to be sufficient to test.  e.g. 'tar cf /dev/null <path>'.  A 'du'
>    would be a good test too.
>

Got these results

dfly-bkpsrv# hammer snapls /Backup2/VersionControl/
Snapshots on (null)     PFS #2
Transaction ID          Timestamp               Note
0x00000001d7b84370      2010-04-26 20:58:18 IST -
0x00000001d9baa2a0      2010-04-27 21:00:36 IST -
0x00000001df97a3d0      2010-04-28 21:02:39 IST -
dfly-bkpsrv# cd @@0x00000001df97a3d0
dfly-bkpsrv# pwd
/Backup2/pfs/@@0x00000001e0e4e730:00002/@@0x00000001b99af1c0/@@0x00000001df97a3d0
dfly-bkpsrv# tar cf /dev/null
/Backup2/pfs/@@0x00000001e0e4e730:00002/@@0x00000001b99af1c0/@@0x00000001df97a3d0
tar: Removing leading '/' from member names
dfly-bkpsrv# echo $?
0
dfly-bkpsrv# du -sh
 58M    .
dfly-bkpsrv#


dfly-bkpsrv# hammer snapls /Backup2/Data/
Snapshots on (null)     PFS #1
Transaction ID          Timestamp               Note
0x00000001cba09f70      2010-04-19 20:30:04 IST -
0x00000001cdb08480      2010-04-20 20:30:06 IST -
0x00000001cfb2b590      2010-04-21 20:30:04 IST -
0x00000001d1b492e0      2010-04-22 20:30:05 IST -
0x00000001d3b66c50      2010-04-23 20:30:01 IST -
0x00000001d7b842d0      2010-04-26 20:30:13 IST -
0x00000001d9b9cee0      2010-04-27 20:30:11 IST -
0x00000001df96c150      2010-04-28 20:30:42 IST -
dfly-bkpsrv# cd @@0x00000001df96c150
dfly-bkpsrv# pwd
/Backup2/pfs/@@0x00000001e0d7e210:00001/@@0x00000001df96c150
dfly-bkpsrv# tar cf /dev/null
/Backup2/pfs/@@0x00000001e0d7e210:00001/@@0x00000001df96c150
tar: Removing leading '/' from member names
tar: /Backup2/pfs/@@0x00000001e0d7e210:00001/@@0x00000001df96c150/Old-Backupsrv/usr/ports/x11/openmotif/w-openmotif-2.1.30.5p1/motif/tests/uil/widgets/BBoardDia.dat:
Cannot stat: No such file or directory
tar: /Backup2/pfs/@@0x00000001e0d7e210:00001/@@0x00000001df96c150/Old-Backupsrv/usr/ports/x11/openmotif/w-openmotif-2.1.30.5p1/motif/tests/visuals/Toolkit/List/List9.prt:
Cannot stat: No such file or directory
tar: /Backup2/pfs/@@0x00000001e0d7e210:00001/@@0x00000001df96c150/Old-Backupsrv/usr/ports/x11/wmpinboard/pkg:
Cannot stat: No such file or directory


So I guess /Backup2/Data/ is corrupt?

>    If things look messed up you may have to destroy the slave PFS and
>    recreate it, which means the mirror-stream will have to push the
>    whole thing all over again.
>

mirror-stream or mirror-copy ?

I guess when I do a mirror-copy I get them back?

Should i be checking the Master PFSes for some reason.
Since I am used to fsck after unclean shutdown and since hammer dont
fsck I some times get a creepy feeling if my filesystem is corrupt in
some corner :-(


>    You don't need to cron the mirror-stream.  The hammer mirror-stream
>    will automatically restart if the connection is lost so you only need
>    to start it up once at boot.  You can do this with an @reboot entry
>    in the crontab.  e.g.:
>
>        @reboot command
>
>    If you still want to do it with a periodic cron, then create a separate
>    cron entry (with a separate lock file) for each stream.
>

no

@reboot is enough :-)

I currently start them with rc.local

Thanks

--Siju