My dump device is already on a different controller - the motherboards built-in nVidia SATA controller.
The raidz2 vdev is the one I'm having trouble with (copying the same files to the mirrored rpool on the nVidia controller work nicely). I do notice that, when using cp to copy the files to the raidz2 pool, load on the machine climbs steadily until the crash, and one proc core pegs at 100%. Frustrating, yes. On Thu, Mar 12, 2009 at 12:31 AM, Maidak Alexander J <maidakalexand...@johndeere.com> wrote: > If you're having issues with a disk contoller or disk IO driver its highly > likely that a savecore to disk after the panic will fail. I'm not sure how > to work around this, maybe a dedicated dump device not on a controller that > uses a different driver then the one that you're having issues with? > > -----Original Message----- > From: zfs-discuss-boun...@opensolaris.org > [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Blake > Sent: Wednesday, March 11, 2009 4:45 PM > To: Richard Elling > Cc: Marc Bevand; zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] reboot when copying large amounts of data > > I guess I didn't make it clear that I had already tried using savecore to > retrieve the core from the dump device. > > I added a larger zvol for dump, to make sure that I wasn't running out of > space on the dump device: > > r...@host:~# dumpadm > Dump content: kernel pages > Dump device: /dev/zvol/dsk/rpool/bigdump (dedicated) Savecore > directory: /var/crash/host > Savecore enabled: yes > > I was using the -L option only to try to get some idea of why the system load > was climbing to 1 during a simple file copy. > > > > On Wed, Mar 11, 2009 at 4:58 PM, Richard Elling <richard.ell...@gmail.com> > wrote: >> Blake wrote: >>> >>> I'm attaching a screenshot of the console just before reboot. The >>> dump doesn't seem to be working, or savecore isn't working. >>> >>> On Wed, Mar 11, 2009 at 11:33 AM, Blake <blake.ir...@gmail.com> wrote: >>> >>>> >>>> I'm working on testing this some more by doing a savecore -L right >>>> after I start the copy. >>>> >>>> >> >> savecore -L is not what you want. >> >> By default, for OpenSolaris, savecore on boot is disabled. But the >> core will have been dumped into the dump slice, which is not used for swap. >> So you should be able to run savecore at a later time to collect the >> core from the last dump. >> -- richard >> >> > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
