- Original Message -
> On 12/04/2011 8:38 a.m., Roy Sigurd Karlsbakk wrote:
> > Persistent mapping is disabled, and has been for some time. lsiutil
> > shows no persistent mappings. The drives are a varity of makes. The
> > system has been the same since I reinstalled it a month or two ba
On 12/04/2011 8:38 a.m., Roy Sigurd Karlsbakk wrote:
Persistent mapping is disabled, and has been for some time. lsiutil shows no
persistent mappings. The drives are a varity of makes. The system has been the
same since I reinstalled it a month or two back.
roy
I would suggest using lsiutil
Persistent mapping is disabled, and has been for some time. lsiutil shows no
persistent mappings. The drives are a varity of makes. The system has been the
same since I reinstalled it a month or two back.
roy
- Original Message -
> Hi Roy,
>
> The drive order issue is likely to be pers
Hi Roy,
The drive order issue is likely to be persistent mapping.
It can be disabled using lsiutil.
I found it was enabled by default on early cards, and disabled on later
ones, but changing the firmware doesn't change the origional setting.
What model are the disks ?
Did the origional system
> This is an entry level proliant, very standard gear. I cannot
> believe that you would be the first one using them with ZFS (those
> sell really well) Is the Jbod configured? I mean, are all the the
> drives correctly defined in whatever config utility provided at boot
> time?
Yes
> Are the dri
This is an entry level proliliant, very standard gear. I cannot
believe that you would be the first one using them with ZFS (those
sell really well) Is the Jbod configured? I mean, are all the the
drives correctly defined in whatever config utility provided at boot
time?
Are the drives in both chas
The server is an HP ProLiant DL120 G5. Controller type is LSI SAS1068E with IT
firmware (no RAID, only JBOD). Disk chassises are one SuperMicro 12-bay 2U and
one SuperMicro 24-bay 4U.
roy
- Original Message -
> Ummm that bug report says the 2 magic keywords: Jbod, and
> Supermicro... An
Ummm that bug report says the 2 magic keywords: Jbod, and
Supermicro... And the motherboard model is a close one too :O
Make sure that jour jbods are configured in whatever type of bios your
controller uses, every drive should be a jbod on its own. This looks
just like the problem I had (and solve
Looks like this bugger
http://comments.gmane.org/gmane.os.solaris.opensolaris.zfs/34796
Anyone that knows how this can be fixed?
roy
- Original Message -
> Hi,
> your list looks very familiar to me;
> I had something similar on a supermicro motherboard, if you did not
> configure all th
Hi,
your list looks very familiar to me;
I had something similar on a supermicro motherboard, if you did not
configure all the independent drives as separate jbods in the raid
controller, the order of the drives was mysteriously swapping at boot
time. Neither ZFS, neither a conventional raid on Li
> It sounds like a bit too much of coincidence that 8 drives have
> failed.
> Maybe a port extender has failed. It would be of interest to know what
> these 8 drives have in common.
They are in two different chassises, so the only thing in common I can see, is
the controller. Also, why on earth d
On 2011-04-11 10:28, Roy Sigurd Karlsbakk wrote:
Hi all
I have this box for backup storage, urd-backup, zfs receiving a copy of another
system, urd. on urd-backup, I created the following pool
zpool create -f urd-backup \
raidz2 c5t0d0 c5t1d0 c5t2d0 c5t3d0 c5t4d0 c5t5d0 c5t6d0 c5t7d0
Hi all
I have this box for backup storage, urd-backup, zfs receiving a copy of another
system, urd. on urd-backup, I created the following pool
zpool create -f urd-backup \
raidz2 c5t0d0 c5t1d0 c5t2d0 c5t3d0 c5t4d0 c5t5d0 c5t6d0 c5t7d0 c5t8d0 \
raidz2 c5t9d0 c5t10d0 c5t11d0 c5t12
13 matches
Mail list logo
