EVA Storage
cancel
Showing results for 
Search instead for 
Did you mean: 

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.