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

[Matthew Dillon]

:Hi,
:
:I don't think any body needs to waste time looking at my core dump.
:
:I had as cron entry
:
:#Check and restart mirroring
:*/10 * * * * (cd /root/adm; /usr/bin/lockf -k -t 0 .lockfile ./hms) &
:
:now hms was initially
:
:dfly-bkpsrv# cat /root/adm/hms
:hammer mirror-stream /Backup1/Data /Backup2/Data &
:hammer mirror-stream /Backup1/VersionControl /Backup2/VersionControl
:
:I had added a 3rd line some time and put an & at the end of the second line.
:Now when I removed the 3rd line i forgot to remove the & at the end of
:the second line and it looked like
:
:dfly-bkpsrv# cat /root/adm/hms
:hammer mirror-stream /Backup1/Data /Backup2/Data &
:hammer mirror-stream /Backup1/VersionControl /Backup2/VersionControl &
:
:So the locking did not work and it started spawning hammer
:mirror-stream processes one after another every 10 mins.
:
:I hope my slave pfses are not corrupted by these crashes :-(
:
:Thanks
:
:--Siju

    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.

    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.

    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.

						-Matt