Hi Remco. Yes, I realize that was asking for trouble. It wasn't supposed to be a test of yanking a LUN. We needed a LUN for a VxVM/VxFS system and that LUN was available. I was just surprised at the panic, since the system was quiesced at the time. But there is coming a time when we will be doing this. Thanks for the feedback. I appreciate it.
----- Original Message ---- From: Remco Lengers <re...@lengers.com> To: Grant Lowe <gl...@sbcglobal.net> Cc: zfs-discuss@opensolaris.org Sent: Thursday, April 9, 2009 5:31:42 AM Subject: Re: [zfs-discuss] ZFS Panic Grant, Didn't see a response so I'll give it a go. Ripping a disk away and silently inserting a new one is asking for trouble imho. I am not sure what you were trying to accomplish but generally replace a drive/lun would entail commands like zpool offline tank c1t3d0 cfgadm | grep c1t3d0 sata1/3::dsk/c1t3d0 disk connected configured ok # cfgadm -c unconfigure sata1/3 Unconfigure the device at: /devices/p...@0,0/pci1022,7...@2/pci11ab,1...@1:3 This operation will suspend activity on the SATA device Continue (yes/no)? yes # cfgadm | grep sata1/3 sata1/3 disk connected unconfigured ok <Replace the physical disk c1t3d0> # cfgadm -c configure sata1/3 Taken from this page: http://docs.sun.com/app/docs/doc/819-5461/gbbzy?a=view ..Remco Grant Lowe wrote: > Hi All, > > Don't know if this is worth reporting, as it's human error. Anyway, I had a > panic on my zfs box. Here's the error: > > marksburg /usr2/glowe> grep panic /var/log/syslog > Apr 8 06:57:17 marksburg savecore: [ID 570001 auth.error] reboot after > panic: assertion failed: 0 == dmu_buf_hold_array(os, object, offset, size, > FALSE, FTAG, &numbufs, &dbp), file: ../../common/fs/zfs/dmu.c, line: 580 > Apr 8 07:15:10 marksburg savecore: [ID 570001 auth.error] reboot after > panic: assertion failed: 0 == dmu_buf_hold_array(os, object, offset, size, > FALSE, FTAG, &numbufs, &dbp), file: ../../common/fs/zfs/dmu.c, line: 580 > marksburg /usr2/glowe> > > What we did to cause this is we pulled a LUN from zfs, and replaced it with a > new LUN. We then tried to shutdown the box, but it wouldn't go down. We had > to send a break to the box and reboot. This is an oracle sandbox, so we're > not really concerned. Ideas? > > _______________________________________________ > 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
