On Fri, Apr 1, 2011 at 4:22 AM, Pete French <petefre...@ingresso.co.uk> wrote: >> The other 5% of the time, the hastd crashes occurred either when >> importing the ZFS pool, or when running multiple parallel rsyncs to >> the pool. hastd was always shown as the last running process in the >> backtrace onscreen. > > This is what I am seeing - did you manage to reproduce this with the patch, > or does it fix the issue for you ? Am doing more test now, with only a single > hast device to see if it is stable. Am Ok to run without mirroring across > hast devices for now, but wouldnt like to do so long term!
I have not been able to crash or hang the box since applying Mikolaj's patch. I've tried the following: - destroy pool - create pool - destroy hast providers - create hast providers - switch from master to slave via hastctl using "role secondary all" - switch from slave to master via hastctl using "role primary all" - switch roles via hast-carp-switch which does one provider per second - import/export pool I've been running 6 parallel rsyncs for the past 48 hours, getting a consistent 200 Mbps of transfers, with just under 2 TB of deduped data in the pool, without any lockups. So far, so good. -- Freddie Cash fjwc...@gmail.com _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
