HPE EVA Storage
1752749 Members
5212 Online
108789 Solutions
New Discussion

LUN presenting issue with EVA6400

 
Dhananjaya Amarakoon
Regular Advisor

LUN presenting issue with EVA6400

Hi,

we have EVA6400 which newly setup and still not in the production. Unfortunately all the 4 cache batteries are failed. But with the resync I can able to  get visible presented vdisk in windows 2003 server ( device and disk manger ). It has  issue which after install the multipart drivers all the presented disks disappear from disk manger,

I have presented vdisk to  RHEL 5.6 (64bit) and tested.

In there I have getting following error in dmesg.

All these related to due to cache battery issue or OS side issue ?

 

few lines of dmesg log as follows

 

===============

Emulex LightPulse Fibre Channel SCSI driver 8.2.0.87.1p
Copyright(c) 2004-2009 Emulex.  All rights reserved.
GSI 24 sharing vector 0xBA and IRQ 24


scsi1 :  on PCI bus 0b device 00 irq 194
lpfc 0000:0e:00.0: 0:1303 Link Up Event x1 received Data: x1 xf7 x20 x9 x0 x0 0
  Vendor: HP        Model: HSV400            Rev: 0953
  Type:   RAID                               ANSI SCSI revision: 05
  Vendor: HP        Model: HSV400            Rev: 0953
  Type:   Direct-Access                      ANSI SCSI revision: 05
sda: Spinning up disk....floppy0: no floppy controllers found
work still pending
lpfc 0000:0b:00.0: 1:1303 Link Up Event x1 received Data: x1 x1 x20 x9 x0 x0 0
  Vendor: HP        Model: HSV400            Rev: 0953
  Type:   RAID                               ANSI SCSI revision: 05
  Vendor: HP        Model: HSV400            Rev: 0953
  Type:   Direct-Access                      ANSI SCSI revision: 05


SCSI device sda: 20971520 512-byte hdwr sectors (10737 MB)
sda: test WP failed, assume Write Enabled
sda: asking for cache data failed
sda: assuming drive cache: write through
sda: Spinning up disk......not responding...
SCSI device sdb: 20971520 512-byte hdwr sectors (10737 MB)
sdb: test WP failed, assume Write Enabled
sdb: asking for cache data failed
sdb: assuming drive cache: write through
sdb: Spinning up disk.......................................................................................................................................................................................................not responding...
SCSI device sda: 20971520 512-byte hdwr sectors (10737 MB)
sda: test WP failed, assume Write Enabled
sda: asking for cache data failed
sda: assuming drive cache: write through
 sda:...not responding...
SCSI device sdb: 20971520 512-byte hdwr sectors (10737 MB)
sdb: test WP failed, assume Write Enabled
sdb: asking for cache data failed
sdb: assuming drive cache: write through

 

===============

 

Need expert guide regarding this

thanks

Dhananjaya

5 REPLIES 5
Johan Guldmyr
Honored Contributor

Re: LUN presenting issue with EVA6400

Hi,

 

I'd bet my ponies on that you need to fix the batteries  before the disks can be utilized by the hosts.

 

There is also a newer firmware out for the 6400 which you may want to give a go (thin provisioning for example..).

Greybeard
Esteemed Contributor

Re: LUN presenting issue with EVA6400

EVA controllers have no write through mode, so no cache protection = no host I/O.
_________________________________________________
How to assign points on this new forum? Click the Kudos Star!
Johan Guldmyr
Honored Contributor

Re: LUN presenting issue with EVA6400

Isn't there an option on the vdisk where you can set the cache mode to write-back or write-through?

Slightly misleading as I believe you still need functional batteries.. 

Uwe Zessin
Honored Contributor

Re: LUN presenting issue with EVA6400

In the old days it was possible to flip write-back and write-through and you could even turn off write-cache-mirroring.

 

As far as I know, *A-L-L* EVAs share the fatal design decision, not to provide an override switch if all cache batteries have failed :-( :-(

.
Johan Guldmyr
Honored Contributor

Re: LUN presenting issue with EVA6400

It's my understanding as well.

This causes annoyance if a move takes too long time or it's shut down for an extended period of time.