zfs discuss - Dec 2005 - ZFS volume is hosing BIOS POST on Ultra20 (BIOS 2.1.7)

I''m a proud owner of a shiny new Sun Ultra 20 Workstation (1 of 10),
and I ordered it with the standard SATA 80GB drive, and a secondary 250GB SATA
drive.

I''ve installed the machine with Nevada 27a, and proceeded to update
things the way I wanted them.

I used ''zpool'' to create a new datapool and assigned the 250GB
SATA drive.  I realize that this isn''t necessarily an optimal use case
with only the one drive assigned, but hey, I want to learn how zfs works and
what better way to do it than to use it.

So, ZFS works like a charm, exactly like the docs said it would.  I''m
creating filesystems, moving mountpoints, assigning quotas, etc....

Then I rebooted...  And my heart sunk when the BIOS POST froze after detecting
the drives, which it did so successfully.  After fiddling for a bit, trying to
understand what was going on, I started the dreary process of elimination. 
Lucky for me, my first inclination was to remove the drives, and add them back,
one by one, so the process of elimination didn''t last long.

The end result was that I pulled the 250GB SATA drive, and the machine posted. 
So like a good consumer, I assumed the drive had died, and proceeded to RMA it. 
In the meantime, I inserted another 250GB SATA drive from another Ultra20 yet to
be deployed (from one of the other 9 we have), and re-created my ZFS pool and
filesystems...  And rebooted.

Wasn''t I surprised to have the same problem?  Then a colleague a few
cubes over stuck his head up and said, "My machine won''t boot! 
WTF is wrong with this thing?"  To which I replied, "Did you ZFS your
data drive?", and his answer was "Yeah, why?  Is there a problem with
that?"

So, you see, a pattern is forming.  If we ZFS a drive, it won''t pass
BIOS POST and boot the machine.  I can''t find a reason for it in any
sunsolve/googling.

Does anyone here have the same experience?

Two drive models that have been used, both Sun Part 540-6521-01, are a Hitachi
Deskstar HDS722525VLSA80, and a Seagate ST3250823AS.

Machine is Sun Ultra 20 (Opteron 148, 2GB RAM) - Running Solaris 5.11 nv27a.

Any tips would be appreciated.  I will be trying nv28 next, but my breath, she
is not being held.  And I''m starting to pile up SATA drives that I
cannot use.

MK
This message posted from opensolaris.org

On Thu 15 Dec 2005 at 02:26PM, Michael Kennedy wrote:
> I''m a proud owner of a shiny new Sun Ultra 20 Workstation (1 of
10),
> and I ordered it with the standard SATA 80GB drive, and a secondary
> 250GB SATA drive.
> 
> I''ve installed the machine with Nevada 27a, and proceeded to
update
> things the way I wanted them.
> 
> I used ''zpool'' to create a new datapool and assigned the
250GB SATA
> drive.  I realize that this isn''t necessarily an optimal use case
with
> only the one drive assigned, but hey, I want to learn how zfs works
> and what better way to do it than to use it.
> 
> So, ZFS works like a charm, exactly like the docs said it would. 
I''m
> creating filesystems, moving mountpoints, assigning quotas, etc....
> 
> Then I rebooted...  And my heart sunk when the BIOS POST froze after
> detecting the drives, which it did so successfully.  After fiddling
> for a bit, trying to understand what was going on, I started the
> dreary process of elimination.  Lucky for me, my first inclination was
> to remove the drives, and add them back, one by one, so the process of
> elimination didn''t last long.
> 
> The end result was that I pulled the 250GB SATA drive, and the machine
> posted.  So like a good consumer, I assumed the drive had died, and
> proceeded to RMA it.  In the meantime, I inserted another 250GB SATA
> drive from another Ultra20 yet to be deployed (from one of the other 9
> we have), and re-created my ZFS pool and filesystems...  And rebooted.
> 
> Wasn''t I surprised to have the same problem?  Then a colleague a
few
> cubes over stuck his head up and said, "My machine won''t
boot!  WTF is
> wrong with this thing?"  To which I replied, "Did you ZFS your
data
> drive?", and his answer was "Yeah, why?  Is there a problem with
> that?"
I had the same problem with my U20--- precisely this sequence.  Let''s
get a bug filed.

        -dp

-- 
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp

On Thu, 2005-12-15 at 17:56, Dan Price wrote:
> I had the same problem with my U20--- precisely this sequence. 
Let''s
> get a bug filed.
sounds to me like the EFI GPT label used by ZFS when you give it the
whole disk is somehow toxic to the BIOS...

						- Bill

On Fri 16 Dec 2005 at 10:22AM, Nathan Kroenert wrote:
> Silly question (I don''t have a U20... :(  )...
> 
> Does the bios have boot sector monitoring (virus checking) capabilities, 
> and is it possible the label ZFS uses is hurting it''s brain?
> 
> Just a thought... :)
It has a virus protection option in the BIOS, but it is off, at least
on mine.  But I''ll dork with the BIOS settings now that I realize it
isn''t a bad drive.

        -dp

-- 
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp

Silly question (I don''t have a U20... :(  )...

Does the bios have boot sector monitoring (virus checking) capabilities, 
and is it possible the label ZFS uses is hurting it''s brain?

Just a thought... :)

Nathan.

Dan Price wrote:
> On Thu 15 Dec 2005 at 02:26PM, Michael Kennedy wrote:
> 
>>I''m a proud owner of a shiny new Sun Ultra 20 Workstation (1 of
10),
>>and I ordered it with the standard SATA 80GB drive, and a secondary
>>250GB SATA drive.
>>
>>I''ve installed the machine with Nevada 27a, and proceeded to
update
>>things the way I wanted them.
>>
>>I used ''zpool'' to create a new datapool and assigned
the 250GB SATA
>>drive.  I realize that this isn''t necessarily an optimal use
case with
>>only the one drive assigned, but hey, I want to learn how zfs works
>>and what better way to do it than to use it.
>>
>>So, ZFS works like a charm, exactly like the docs said it would. 
I''m
>>creating filesystems, moving mountpoints, assigning quotas, etc....
>>
>>Then I rebooted...  And my heart sunk when the BIOS POST froze after
>>detecting the drives, which it did so successfully.  After fiddling
>>for a bit, trying to understand what was going on, I started the
>>dreary process of elimination.  Lucky for me, my first inclination was
>>to remove the drives, and add them back, one by one, so the process of
>>elimination didn''t last long.
>>
>>The end result was that I pulled the 250GB SATA drive, and the machine
>>posted.  So like a good consumer, I assumed the drive had died, and
>>proceeded to RMA it.  In the meantime, I inserted another 250GB SATA
>>drive from another Ultra20 yet to be deployed (from one of the other 9
>>we have), and re-created my ZFS pool and filesystems...  And rebooted.
>>
>>Wasn''t I surprised to have the same problem?  Then a colleague
a few
>>cubes over stuck his head up and said, "My machine won''t
boot!  WTF is
>>wrong with this thing?"  To which I replied, "Did you ZFS your
data
>>drive?", and his answer was "Yeah, why?  Is there a problem
with
>>that?"
> 
> 
> I had the same problem with my U20--- precisely this sequence. 
Let''s
> get a bug filed.
> 
>         -dp
>

On Thu, Dec 15, 2005 at 06:13:47PM -0500, Bill Sommerfeld
wrote:
> On Thu, 2005-12-15 at 17:56, Dan Price wrote:
> > I had the same problem with my U20--- precisely this sequence. 
Let''s
> > get a bug filed.
> 
> sounds to me like the EFI GPT label used by ZFS when you give it the
> whole disk is somehow toxic to the BIOS...
This is a recently discovered bug (by James Gosling, no less).  It seems
to be, as Bill S. points out, caused by the EFI label that ZFS uses.  It
interacts with the BIOS RAID configuration scanning code in some evil
way.  A bug has been filed and is being aggressively pursued by both Sun,
the BIOS vendor, and the Nvidia RAID folks.  The problem should go away
if you manually format the disk with a Sun VTOC label, then give ZFS a
slice:  zpool create mypool c2d0s0

The way I''ve worked around this is by unplugging the drive until the
GRUB boot screen comes up, then hot-plugging the drive in and booting
Solaris.  YMMV.


--Bill

Thanks for the insight Bill.  It''s appreciated.  I will attempt the
hot-plug ritual tomorrow morning, and if the gods are smiling, I will be able to
VTOC & get on with my life.

ZFS is showing incredible potential, and I''m discovering more uses than
any of the marketing material that has been spewing since ''04 has
eluded to.  I can''t wait for this to go GA.  This is a disruptive
technology.

Unfortunately I''m getting ahead of myself, imagining potential uses,
and solutioning problems that don''t exist...  As we are all prone to do
from time to time.

Thanks again for the steer.

MK
This message posted from opensolaris.org

>I had the same problem with my U20--- precisely this sequence. 
Let''s
>get a bug filed.

Can you remove the drive fromt he boot sequence?  I''ve seen this
happen when a Tyan 2885 wanted to boot from an EFI labelled
disk.

Casper

On Thu 15 Dec 2005 at 04:36PM, Bill Moore wrote:
> On Thu, Dec 15, 2005 at 06:13:47PM -0500, Bill Sommerfeld wrote:
> > On Thu, 2005-12-15 at 17:56, Dan Price wrote:
> > > I had the same problem with my U20--- precisely this sequence. 
Let''s
> > > get a bug filed.
> > 
> > sounds to me like the EFI GPT label used by ZFS when you give it the
> > whole disk is somehow toxic to the BIOS...
> 
> This is a recently discovered bug (by James Gosling, no less).  It seems
> to be, as Bill S. points out, caused by the EFI label that ZFS uses.  It
> interacts with the BIOS RAID configuration scanning code in some evil
> way.  A bug has been filed and is being aggressively pursued by both Sun,
> the BIOS vendor, and the Nvidia RAID folks.  The problem should go away
BugID?
> if you manually format the disk with a Sun VTOC label, then give ZFS a
> slice:  zpool create mypool c2d0s0
> 
> The way I''ve worked around this is by unplugging the drive until
the
> GRUB boot screen comes up, then hot-plugging the drive in and booting
> Solaris.  YMMV.
I tried that, and I just wound up with a sad machine; the second drive
never got recognized, and things like format would hang for a long
while before giving up.

I also filed a bug (6364104), which maybe can now be closed as a dup.

        -dp

-- 
Daniel Price - Solaris Kernel Engineering - dp at eng.sun.com - blogs.sun.com/dp

On Fri, Dec 16, 2005 at 12:02:17AM -0800, Dan Price
wrote:
> > way.  A bug has been filed and is being aggressively pursued by both
Sun,
> > the BIOS vendor, and the Nvidia RAID folks.  The problem should go
away
> 
> BugID?
CR 6363449 I''d guess.

  Scott

> >I had the same problem with my U20--- precisely this
> sequence.  Let''s
> >get a bug filed.
> 
> 
> Can you remove the drive fromt he boot sequence?
>  I''ve seen this
> happen when a Tyan 2885 wanted to boot from an EFI
> labelled
> disk.
Same thing happened to me on my MSI K8N Neo4 Platinum based system - I just  set
the drive type to "None".
This message posted from opensolaris.org

SInce EFI is an Intel (sponsored?) standard, why are *we* just now seeing this? 
Shouldn''t everyone who does EFI see this?
 -- richard
This message posted from opensolaris.org

On 12/16/05, Richard Elling <Richard.Elling at sun.com>
wrote:
> SInce EFI is an Intel (sponsored?) standard, why are *we* just now seeing
this?  Shouldn''t everyone who does EFI see this?
Richard,

EFI was designed for IA64 architecture and GPT label (aka EFI label in Solaris)
is used there. Add to this the fact that PC BIOS usually cannot cope
(didn''t we just
see that :-Q) with the EFI label and here is what we have - most of
the PC (UNIX/Win)
users just have no reason to put EFI label on their disks. ZFS just
changed this.
Oh, BTW, before ZFS one couldn''t put an EFI label on [S]ATA drive at
all even
in Solaris. I think that explains the situation.


--
Regards,
        Cyril

>EFI was designed for IA64 architecture and GPT label (aka EFI label in
Solaris)
>is used there. Add to this the fact that PC BIOS usually cannot cope
>(didn''t we just
>see that :-Q) with the EFI label and here is what we have - most of
>the PC (UNIX/Win)
>users just have no reason to put EFI label on their disks. ZFS just
>changed this.
>Oh, BTW, before ZFS one couldn''t put an EFI label on [S]ATA drive
at all even
>in Solaris. I think that explains the situation.
And that was a *very* recent putback; hit the gates in the two weeks
before zfs, I believe.

So the exposure of the new feature was very limited before zfs
came out..

Casper

I had nv_28 on a SPARC machine with 6 12 disk multipacks. I created a 
pool and several filesystems.
(no data yet though.) Today I ran ''zpool export'' and then
jumpstarted to
nv_29. After booting up I ran ''zpool import'' and the ouput
looked like
below.

I''m pretty sure there wasn''t any thing wrong with the disks
before re
jumpstarting.
But what I find suspicious is that it says ''c3t2d0'' is
missing, and then
says ''c3t2d0s0'' is OK and ONLINE. Which is it?

''c0'' is the boot disk controler. But there are 3 dual ultra
scsi
controllers in this box, so there really should be a ''c6''
somewhere too.

Does this look fishy to anyone else?

    -Kyle



bell# zpool import
  pool: datapool0
    id: 17061535701658615450
 state: DEGRADED
status: One or more devices are missing from the system.
action: The pool can be imported despite missing or damaged devices.  The
        fault tolerance of the pool may be compromised if imported.
   see: http://www.sun.com/msg/ZFS-8000-2Q
config:

        datapool0      DEGRADED
          raidz        DEGRADED
            c1t2d0s0   ONLINE
            c2t2d0s0   ONLINE
            c3t2d0     FAULTED   cannot open
            c3t2d0s0   ONLINE
            c4t2d0s0   ONLINE
            c5t2d0s0   ONLINE
          raidz        DEGRADED
            c1t3d0s0   ONLINE
            c2t3d0s0   ONLINE
            c3t3d0     FAULTED   cannot open
            c3t3d0s0   ONLINE
            c4t3d0s0   ONLINE
            c5t3d0s0   ONLINE
          raidz        DEGRADED
            c1t4d0s0   ONLINE
            c2t4d0s0   ONLINE
            c3t4d0     FAULTED   cannot open
            c3t4d0s0   ONLINE
            c4t4d0s0   ONLINE
            c5t4d0s0   ONLINE
          raidz        DEGRADED
            c1t5d0s0   ONLINE
            c2t5d0s0   ONLINE
            c3t5d0     FAULTED   cannot open
            c3t5d0s0   ONLINE
            c4t5d0s0   ONLINE
            c5t5d0s0   ONLINE
          raidz        DEGRADED
            c1t8d0s0   ONLINE
            c2t8d0s0   ONLINE
            c3t8d0     FAULTED   cannot open
            c3t8d0s0   ONLINE
            c4t8d0s0   ONLINE
            c5t8d0s0   ONLINE
          raidz        DEGRADED
            c1t9d0s0   ONLINE
            c2t9d0s0   ONLINE
            c3t9d0     FAULTED   cannot open
            c3t9d0s0   ONLINE
            c4t9d0s0   ONLINE
            c5t9d0s0   ONLINE
          raidz        DEGRADED
            c1t10d0s0  ONLINE
            c2t10d0s0  ONLINE
            c3t10d0    FAULTED   cannot open
            c3t10d0s0  ONLINE
            c4t10d0s0  ONLINE
            c5t10d0s0  ONLINE
          raidz        DEGRADED
            c1t11d0s0  ONLINE
            c2t11d0s0  ONLINE
            c3t11d0    FAULTED   cannot open
            c3t11d0s0  ONLINE
            c4t11d0s0  ONLINE
            c5t11d0s0  ONLINE
          raidz        DEGRADED
            c1t12d0s0  ONLINE
            c2t12d0s0  ONLINE
            c3t12d0    FAULTED   cannot open
            c3t12d0s0  ONLINE
            c4t12d0s0  ONLINE
            c5t12d0s0  ONLINE
          raidz        DEGRADED
            c1t13d0s0  ONLINE
            c2t13d0s0  ONLINE
            c3t13d0    FAULTED   cannot open
            c3t13d0s0  ONLINE
            c4t13d0s0  ONLINE
            c5t13d0s0  ONLINE
          raidz        DEGRADED
            c1t14d0s0  ONLINE
            c2t14d0s0  ONLINE
            c3t14d0    FAULTED   cannot open
            c3t14d0s0  ONLINE
            c4t14d0s0  ONLINE
            c5t14d0s0  ONLINE
          raidz        DEGRADED
            c1t15d0s0  ONLINE
            c2t15d0s0  ONLINE
            c3t15d0    FAULTED   cannot open
            c3t15d0s0  ONLINE
            c4t15d0s0  ONLINE
            c5t15d0s0  ONLINE
bell#

Yes, this is probably related to:

6362672 import gets confused about overlapping slices

When you created this pool, did you use whole disks?   This might also
be related to:

6344272 re-think how whole disks are stored

The latter should be fixed in build 31; the former is on my short list.
This may also be a new pathology.  Can you recreate this?  Can you send
the output of ''zpool status'' before exporting the pool?

Thanks.

- Eric

On Wed, Dec 21, 2005 at 12:17:33PM -0500, Kyle McDonald
wrote:
> I had nv_28 on a SPARC machine with 6 12 disk multipacks. I created a 
> pool and several filesystems.
> (no data yet though.) Today I ran ''zpool export'' and then
jumpstarted to
> nv_29. After booting up I ran ''zpool import'' and the
ouput looked like
> below.
> 
> I''m pretty sure there wasn''t any thing wrong with the
disks before re
> jumpstarting.
> But what I find suspicious is that it says ''c3t2d0'' is
missing, and then
> says ''c3t2d0s0'' is OK and ONLINE. Which is it?
> 
> ''c0'' is the boot disk controler. But there are 3 dual
ultra scsi
> controllers in this box, so there really should be a ''c6''
somewhere too.
> 
> Does this look fishy to anyone else?
> 
>    -Kyle
> 
> 
> 
> bell# zpool import
>  pool: datapool0
>    id: 17061535701658615450
> state: DEGRADED
> status: One or more devices are missing from the system.
> action: The pool can be imported despite missing or damaged devices.  The
>        fault tolerance of the pool may be compromised if imported.
>   see: http://www.sun.com/msg/ZFS-8000-2Q
> config:
> 
>        datapool0      DEGRADED
>          raidz        DEGRADED
>            c1t2d0s0   ONLINE
>            c2t2d0s0   ONLINE
>            c3t2d0     FAULTED   cannot open
>            c3t2d0s0   ONLINE
>            c4t2d0s0   ONLINE
>            c5t2d0s0   ONLINE
>          raidz        DEGRADED
>            c1t3d0s0   ONLINE
>            c2t3d0s0   ONLINE
>            c3t3d0     FAULTED   cannot open
>            c3t3d0s0   ONLINE
>            c4t3d0s0   ONLINE
>            c5t3d0s0   ONLINE
>          raidz        DEGRADED
>            c1t4d0s0   ONLINE
>            c2t4d0s0   ONLINE
>            c3t4d0     FAULTED   cannot open
>            c3t4d0s0   ONLINE
>            c4t4d0s0   ONLINE
>            c5t4d0s0   ONLINE
>          raidz        DEGRADED
>            c1t5d0s0   ONLINE
>            c2t5d0s0   ONLINE
>            c3t5d0     FAULTED   cannot open
>            c3t5d0s0   ONLINE
>            c4t5d0s0   ONLINE
>            c5t5d0s0   ONLINE
>          raidz        DEGRADED
>            c1t8d0s0   ONLINE
>            c2t8d0s0   ONLINE
>            c3t8d0     FAULTED   cannot open
>            c3t8d0s0   ONLINE
>            c4t8d0s0   ONLINE
>            c5t8d0s0   ONLINE
>          raidz        DEGRADED
>            c1t9d0s0   ONLINE
>            c2t9d0s0   ONLINE
>            c3t9d0     FAULTED   cannot open
>            c3t9d0s0   ONLINE
>            c4t9d0s0   ONLINE
>            c5t9d0s0   ONLINE
>          raidz        DEGRADED
>            c1t10d0s0  ONLINE
>            c2t10d0s0  ONLINE
>            c3t10d0    FAULTED   cannot open
>            c3t10d0s0  ONLINE
>            c4t10d0s0  ONLINE
>            c5t10d0s0  ONLINE
>          raidz        DEGRADED
>            c1t11d0s0  ONLINE
>            c2t11d0s0  ONLINE
>            c3t11d0    FAULTED   cannot open
>            c3t11d0s0  ONLINE
>            c4t11d0s0  ONLINE
>            c5t11d0s0  ONLINE
>          raidz        DEGRADED
>            c1t12d0s0  ONLINE
>            c2t12d0s0  ONLINE
>            c3t12d0    FAULTED   cannot open
>            c3t12d0s0  ONLINE
>            c4t12d0s0  ONLINE
>            c5t12d0s0  ONLINE
>          raidz        DEGRADED
>            c1t13d0s0  ONLINE
>            c2t13d0s0  ONLINE
>            c3t13d0    FAULTED   cannot open
>            c3t13d0s0  ONLINE
>            c4t13d0s0  ONLINE
>            c5t13d0s0  ONLINE
>          raidz        DEGRADED
>            c1t14d0s0  ONLINE
>            c2t14d0s0  ONLINE
>            c3t14d0    FAULTED   cannot open
>            c3t14d0s0  ONLINE
>            c4t14d0s0  ONLINE
>            c5t14d0s0  ONLINE
>          raidz        DEGRADED
>            c1t15d0s0  ONLINE
>            c2t15d0s0  ONLINE
>            c3t15d0    FAULTED   cannot open
>            c3t15d0s0  ONLINE
>            c4t15d0s0  ONLINE
>            c5t15d0s0  ONLINE
> bell#
> 
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Eric Schrock wrote:
> Yes, this is probably related to:
>
> 6362672 import gets confused about overlapping slices
>
> When you created this pool, did you use whole disks?   This might also
> be related to:
>
> 6344272 re-think how whole disks are stored
>
> The latter should be fixed in build 31; the former is on my short list.
> This may also be a new pathology.  Can you recreate this?  Can you send
> the output of ''zpool status'' before exporting the pool?
>
> Thanks.
>
>   
I think I figured it out. maybe this will help you:

One of the multipacks was confused. I power cycled it, and ran
''disks'',
''drvconfig'', and ''devlinks'' and c6 showed
up.  This c6 should have been
numbered c3 if it had been found during the jumpstart, but since the 
disks on it were wacked it didn''t get a number at all.

I think the missing c3 in the output is zpool showing me the name of the 
device the last time it was present. The other c3 is the name of the 
device that currently is in the c3 position, but which used to be in the 
c4 position. Since the controller was missing entirely, there wasn''t
any
name to replace the old c3 with. Maybe zpool should print
''missing'' instead?

    -Kyle
> - Eric
>
> On Wed, Dec 21, 2005 at 12:17:33PM -0500, Kyle McDonald wrote:
>   
>> I had nv_28 on a SPARC machine with 6 12 disk multipacks. I created a 
>> pool and several filesystems.
>> (no data yet though.) Today I ran ''zpool export'' and
then jumpstarted to
>> nv_29. After booting up I ran ''zpool import'' and the
ouput looked like
>> below.
>>
>> I''m pretty sure there wasn''t any thing wrong with the
disks before re
>> jumpstarting.
>> But what I find suspicious is that it says ''c3t2d0''
is missing, and then
>> says ''c3t2d0s0'' is OK and ONLINE. Which is it?
>>
>> ''c0'' is the boot disk controler. But there are 3 dual
ultra scsi
>> controllers in this box, so there really should be a
''c6'' somewhere too.
>>
>> Does this look fishy to anyone else?
>>
>>    -Kyle
>>
>>
>>
>> bell# zpool import
>>  pool: datapool0
>>    id: 17061535701658615450
>> state: DEGRADED
>> status: One or more devices are missing from the system.
>> action: The pool can be imported despite missing or damaged devices. 
The
>>        fault tolerance of the pool may be compromised if imported.
>>   see: http://www.sun.com/msg/ZFS-8000-2Q
>> config:
>>
>>        datapool0      DEGRADED
>>          raidz        DEGRADED
>>            c1t2d0s0   ONLINE
>>            c2t2d0s0   ONLINE
>>            c3t2d0     FAULTED   cannot open
>>            c3t2d0s0   ONLINE
>>            c4t2d0s0   ONLINE
>>            c5t2d0s0   ONLINE
>>          raidz        DEGRADED
>>            c1t3d0s0   ONLINE
>>            c2t3d0s0   ONLINE
>>            c3t3d0     FAULTED   cannot open
>>            c3t3d0s0   ONLINE
>>            c4t3d0s0   ONLINE
>>            c5t3d0s0   ONLINE
>>          raidz        DEGRADED
>>            c1t4d0s0   ONLINE
>>            c2t4d0s0   ONLINE
>>            c3t4d0     FAULTED   cannot open
>>            c3t4d0s0   ONLINE
>>            c4t4d0s0   ONLINE
>>            c5t4d0s0   ONLINE
>>          raidz        DEGRADED
>>            c1t5d0s0   ONLINE
>>            c2t5d0s0   ONLINE
>>            c3t5d0     FAULTED   cannot open
>>            c3t5d0s0   ONLINE
>>            c4t5d0s0   ONLINE
>>            c5t5d0s0   ONLINE
>>          raidz        DEGRADED
>>            c1t8d0s0   ONLINE
>>            c2t8d0s0   ONLINE
>>            c3t8d0     FAULTED   cannot open
>>            c3t8d0s0   ONLINE
>>            c4t8d0s0   ONLINE
>>            c5t8d0s0   ONLINE
>>          raidz        DEGRADED
>>            c1t9d0s0   ONLINE
>>            c2t9d0s0   ONLINE
>>            c3t9d0     FAULTED   cannot open
>>            c3t9d0s0   ONLINE
>>            c4t9d0s0   ONLINE
>>            c5t9d0s0   ONLINE
>>          raidz        DEGRADED
>>            c1t10d0s0  ONLINE
>>            c2t10d0s0  ONLINE
>>            c3t10d0    FAULTED   cannot open
>>            c3t10d0s0  ONLINE
>>            c4t10d0s0  ONLINE
>>            c5t10d0s0  ONLINE
>>          raidz        DEGRADED
>>            c1t11d0s0  ONLINE
>>            c2t11d0s0  ONLINE
>>            c3t11d0    FAULTED   cannot open
>>            c3t11d0s0  ONLINE
>>            c4t11d0s0  ONLINE
>>            c5t11d0s0  ONLINE
>>          raidz        DEGRADED
>>            c1t12d0s0  ONLINE
>>            c2t12d0s0  ONLINE
>>            c3t12d0    FAULTED   cannot open
>>            c3t12d0s0  ONLINE
>>            c4t12d0s0  ONLINE
>>            c5t12d0s0  ONLINE
>>          raidz        DEGRADED
>>            c1t13d0s0  ONLINE
>>            c2t13d0s0  ONLINE
>>            c3t13d0    FAULTED   cannot open
>>            c3t13d0s0  ONLINE
>>            c4t13d0s0  ONLINE
>>            c5t13d0s0  ONLINE
>>          raidz        DEGRADED
>>            c1t14d0s0  ONLINE
>>            c2t14d0s0  ONLINE
>>            c3t14d0    FAULTED   cannot open
>>            c3t14d0s0  ONLINE
>>            c4t14d0s0  ONLINE
>>            c5t14d0s0  ONLINE
>>          raidz        DEGRADED
>>            c1t15d0s0  ONLINE
>>            c2t15d0s0  ONLINE
>>            c3t15d0    FAULTED   cannot open
>>            c3t15d0s0  ONLINE
>>            c4t15d0s0  ONLINE
>>            c5t15d0s0  ONLINE
>> bell#
>>
>>
>> _______________________________________________
>> zfs-discuss mailing list
>> zfs-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>>     
>
> --
> Eric Schrock, Solaris Kernel Development      
http://blogs.sun.com/eschrock
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>

On Wed, Dec 21, 2005 at 02:06:43PM -0500, Kyle McDonald
wrote:
> 
> One of the multipacks was confused. I power cycled it, and ran
''disks'',
> ''drvconfig'', and ''devlinks'' and c6
showed up.  This c6 should have been
> numbered c3 if it had been found during the jumpstart, but since the 
> disks on it were wacked it didn''t get a number at all.
> 
> I think the missing c3 in the output is zpool showing me the name of the 
> device the last time it was present. The other c3 is the name of the 
> device that currently is in the c3 position, but which used to be in the 
> c4 position. Since the controller was missing entirely, there
wasn''t any
> name to replace the old c3 with. Maybe zpool should print
''missing'' instead?
>
OK.  That makes sense.  The additional ''s0'' additions are due
to the
whole-disk bug, and will be fixed soon.

This could probably be made a little more explicit, but it gets
difficult once you actually import the pool.  If we were to import your
pool, we would not know whether ''c3t0d0'' was the right name of
the
device or not.  Note that once you plugged the disk in, we would
correctly open it by devid and all would be well, modulo this bug:

6364582 need to fixup paths if they''ve changed

Which doesn''t affect correctness, but can produce confusing output when
using zpool(1M).  For example, what if you had:

	pool
	  mirror
	    c0t1d0	ONLINE
	    c0t1d0	OFFLINE		cannot open
	    c0t2d0	ONLINE

Is there any way to display this in a non-confusing manner?  One
possibility is that if there is a device with the given path, but it
doesn''t match the one we''re expecting, then we display it
differently,
either with ''missing'', or marking the path somehow, like
"(c0t1d0)".
Would any of this help?

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

>	pool
>	  mirror
>	    c0t1d0	ONLINE
>	    c0t1d0	OFFLINE		cannot open
>	    c0t2d0	ONLINE
>
>Is there any way to display this in a non-confusing manner?  One
>possibility is that if there is a device with the given path, but it
>doesn''t match the one we''re expecting, then we display it
differently,
>either with ''missing'', or marking the path somehow, like
"(c0t1d0)".
>Would any of this help?

If I may suggest *not* mentioning the device name at all?

Whatever way you present it, it is going to be confusing.

In this case we''d have c0t1d0 and (c0t1d0).  Now the user may
well say "but c0t1d0 is there, it''s c1t1d0 that''s gone
missing!.

It makes much more sense to use some WNN id.

Casper

Eric Schrock wrote:
> On Wed, Dec 21, 2005 at 02:06:43PM -0500, Kyle McDonald wrote:
>   
>> One of the multipacks was confused. I power cycled it, and ran
''disks'',
>> ''drvconfig'', and ''devlinks'' and c6
showed up.  This c6 should have been
>> numbered c3 if it had been found during the jumpstart, but since the 
>> disks on it were wacked it didn''t get a number at all.
>>
>> I think the missing c3 in the output is zpool showing me the name of
the
>> device the last time it was present. The other c3 is the name of the 
>> device that currently is in the c3 position, but which used to be in
the
>> c4 position. Since the controller was missing entirely, there
wasn''t any
>> name to replace the old c3 with. Maybe zpool should print
''missing'' instead?
>>
>>     
>
> OK.  That makes sense.  The additional ''s0'' additions are
due to the
> whole-disk bug, and will be fixed soon.
>
> This could probably be made a little more explicit, but it gets
> difficult once you actually import the pool.  If we were to import your
> pool, we would not know whether ''c3t0d0'' was the right
name of the
> device or not.  Note that once you plugged the disk in, we would
> correctly open it by devid and all would be well, modulo this bug:
>
> 6364582 need to fixup paths if they''ve changed
>
> Which doesn''t affect correctness, but can produce confusing output
when
> using zpool(1M).  For example, what if you had:
>
> 	pool
> 	  mirror
> 	    c0t1d0	ONLINE
> 	    c0t1d0	OFFLINE		cannot open
> 	    c0t2d0	ONLINE
>
> Is there any way to display this in a non-confusing manner?  One
> possibility is that if there is a device with the given path, but it
> doesn''t match the one we''re expecting, then we display it
differently,
> either with ''missing'', or marking the path somehow, like
"(c0t1d0)".
> Would any of this help?
>   
I would think:

	pool
	  mirror
	    c0t1d0	ONLINE
	    missing	OFFLINE		cannot open (was c0t1d0)
	    c0t2d0	ONLINE

Would be the most useful.

	-Kyle

On Wed, Dec 21, 2005 at 04:09:14PM -0500, Kyle McDonald
wrote:
>
> I would think:
> 
> 	pool
> 	  mirror
> 	    c0t1d0	ONLINE
> 	    missing	OFFLINE		cannot open (was c0t1d0)
> 	    c0t2d0	ONLINE
This makes sense.  We can do this for the following cases:

1. During import, if during our device scan we never touched the disk in
   question.

2. For an active pool, if the path is valid, but doesn''t refer to the
   device we expect it to be.

However, if we have an active pool whose path and devid are invalid,
does it still make sense to display "(was c0t1d0)"?  For example, if I
unplug a USB device, or a network attached drive goes away for some
reason, does it make sense to display it as if the path is somehow
wrong?  At this point we can''t tell if the path is right or not -
can/should we distinguish between these cases?

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

>I would think:
>
>	pool
>	  mirror
>	    c0t1d0	ONLINE
>	    missing	OFFLINE		cannot open (was c0t1d0)
>	    c0t2d0	ONLINE
>
>Would be the most useful.

I''m still not sure how useful this is; if the device was moved from
one system to another, the controller number could very well be wrong.

The unique identifier would be a better indicator; perhaps, if it''s
available, disk brand and serial.

Casper

On Wed, Dec 21, 2005 at 10:22:20PM +0100, Casper.Dik at sun.com
wrote:
> 
> I''m still not sure how useful this is; if the device was moved
from
> one system to another, the controller number could very well be wrong.
Except that it may very well clue the admin into what went wrong.  If
they notice, for example, that every disk that was on (former)
controller 3 is mising, it suggests that they didn''t quite connect
controller 3 correctly, even though it is now controller 6.
> The unique identifier would be a better indicator; perhaps, if
it''s
> available, disk brand and serial.
I disagree.  If we had a unique identifier that was in any way
intelligible to the user, this would make sense.  We have both a 64-bit
GUID and a device ID, neither of which provide any useful input to the
administrator on how to fix the problem.  In the example here, how would
a bunch of devids like ''SEAGATE at
WWC49384598610004949993999/SS3948829" be
any indication of the real problem (controller 6 was setup incorrectly)?

- Eric

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock

Perhaps we should allow users to name disks when they''re added, as well
as labeling them with the internal ID? Then there''d be an identifier --
unique if the user is careful -- which was meaningful.
This message posted from opensolaris.org

Is there an BIOS uptade for Ultra20 to make it understand EFI?
 
 
This message posted from opensolaris.org

>Is there an BIOS uptade for Ultra20 to make it understand EFI?

Understanding EFI is perhaps asking too much; but I believe the
latest BIOS no longer hangs/crashes when it encountered EFI labels
on disks it examines.  (All disks it probes)

Casper

Hello Casper,

Monday, January 22, 2007, 2:56:16 PM, you wrote:
>>Is there an BIOS uptade for Ultra20 to make it understand EFI?

CDSC> Understanding EFI is perhaps asking too much; but I believe the
CDSC> latest BIOS no longer hangs/crashes when it encountered EFI labels
CDSC> on disks it examines.  (All disks it probes)

That''s what we looked for. Somehow my friend missed that.
Thank you.

-- 
Best regards,
 Robert                            mailto:rmilkowski at task.gda.pl
                                       http://milek.blogspot.com

I had the same issue with zfs killing my Ultra20. I can confirm that flashing
the BIOS fixed the issue.

http://www.sun.com/desktop/workstation/ultra20/downloads.jsp#Ultra

Eric
 
 
This message posted from opensolaris.org