zfs discuss - Jul 2009 - [indiana-discuss] zfs issues?

On 28/07/2009, at 6:44 AM, dick hoogendijk wrote:
> Are there any known issues with zfs in OpenSolaris B118?
> I run my pools formatted like the original release 2009.06 (I want to
> be able to go back to it ;-). I''m a bit scared after reading about
> serious issues in B119 (will be skipped, I heard). But B118 is
"safe"?
Well, actually, I have an issue with ZFS under b118 on osol.

Under b117, I attached a second disk to my root pool and confirmed  
everything worked fine.  Rebooted with the disks in reverse order to  
prove grub install worked and everything was fine.  Removed one of the  
spindles, did an upgrade to b118, rebooted and tested and then  
rebooted and added the removed volume, this was an explicit test of  
automated resilvering and it worked perfectly.  Did one or two  
explicit scrubs along the way and they were fine too.

So then I upgrade my zpool from version 14 to version 16 and now zpool  
scrub rpool hangs the ZFS subsystem.  The machine still runs, it''s  
pingable etc, but anything that goes to disk (at least rpool) hangs  
indefinitely.  This happens whether I boot with the mirror in tact or  
degraded with one spindle removed.

I had help trying to create a crash dump, but everything we tried  
didn''t cause the system to panic.  0>eip;:c;:c and other weird magic
I
don''t fully grok

Has anybody else seen this weirdness?

cheers,
James

James Lever wrote:
> I had help trying to create a crash dump, but everything we tried
didn''t
> cause the system to panic.  0>eip;:c;:c and other weird magic I
don''t
> fully grok
I can''t help with your ZFS issue, but to get a reasonable crash
dump in circumstances like these, you should be able to do
"savecore -L" on OpenSolaris.

Rob T

On 28/07/2009, at 9:22 AM, Robert Thurlow wrote:
> I can''t help with your ZFS issue, but to get a reasonable crash
> dump in circumstances like these, you should be able to do
> "savecore -L" on OpenSolaris.
That would be well and good if I could get a login - due to the rpool  
being unresponsive, that was not possible.

So the only recourse we had was via kmdb :/  Is there a way to  
explicitly invoke savecore via kmdb?

James

Yes:

$<systemdump

should do the trick.

Make sure your dumpadm is set up beforehand to enable savecore, and that 
you have a dump device. In my case the output looks like this:

$ pfexec dumpadm
      Dump content: kernel pages
       Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash/opensolaris
  Savecore enabled: yes


Then you should get a dump saved in /var/crash/<hostname> on next reboot.

Brian

James Lever wrote:
>
> On 28/07/2009, at 9:22 AM, Robert Thurlow wrote:
>
>> I can''t help with your ZFS issue, but to get a reasonable
crash
>> dump in circumstances like these, you should be able to do
>> "savecore -L" on OpenSolaris.
>
> That would be well and good if I could get a login - due to the rpool 
> being unresponsive, that was not possible.
>
> So the only recourse we had was via kmdb :/  Is there a way to 
> explicitly invoke savecore via kmdb?
>
> James
>
> _______________________________________________
> indiana-discuss mailing list
> indiana-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
-- 
Brian Ruthven
Solaris Revenue Product Engineering
Sun Microsystems UK
Sparc House, Guillemont Park, Camberley, GU17 9QG

Thanks for that Brian.

I''ve logged a bug:

CR 6865661 *HOT* Created, P1 opensolaris/triage-queue zfs scrub rpool  
causes zpool hang



Just discovered after trying to create a further crash dump that it''s  
failing and rebooting with the following error (just caught it prior  
to the reboot):



panic dump timeout



so I''m not sure how else to assist with debugging this issue.



cheers,

James



On 28/07/2009, at 9:08 PM, Brian Ruthven - Solaris Network Sustaining  
- Sun UK wrote:
> Yes:
>
> $<systemdump
>
> should do the trick.
>
> Make sure your dumpadm is set up beforehand to enable savecore, and  
> that you have a dump device. In my case the output looks like this:
>
> $ pfexec dumpadm
>     Dump content: kernel pages
>      Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
> Savecore directory: /var/crash/opensolaris
> Savecore enabled: yes
>
>
> Then you should get a dump saved in /var/crash/<hostname> on next  
> reboot.
>
> Brian

On 29/07/2009, at 12:00 AM, James Lever wrote:
> CR 6865661 *HOT* Created, P1 opensolaris/triage-queue zfs scrub  
> rpool causes zpool hang
This bug I logged has been marked as related to CR 6843235 which is  
fixed in snv 119.

cheers,
James