Re: [MLUG - DISCUSSION] "missing" files after hard crash or power failure

[Dave Lloyd <EMAIL:PROTECTED>]

On Mon, 2 Apr 2007, shawn parker wrote:

> both servers are dell poweredges using perc raid controllers. like i
> said previously, the /home partition is local but the /arcgis is
> stored on the san (dell emc).

Ah.  LSI RAID controlers.  You've probably got several MB out there.
Usually they won't let you enable the write cache unless you have the
battery backup installed so the memory is saved in the event of a power
failure.

> i don't see how local drive cache would be an issue at least with
> /arcgis. i think /arcgis is a raid 10 lun; i'll have to check
> navisphere.

Well, if the raid LUN is on the raid controler, then you're going
through the RAID controler's write cache.  Likely (hopefully) the write
cache on the individual disks on the RAID have been turned off.
Otherwise, you'd have unpredicitable behavior.  It might be worth
configuring the LUN as a JBOD, using hdparm to investigate the
parameters and then reconfiguring as a RAID 10 again with the same
paramaters without initializing the disks.  In theory you should be able
to do this and still remount your partitions as configing as a JBOD then
back to RAID 10 WITHOUT initializing should preserve your data.  At most
you may have to repartition the lun with the same parameters, but even
that will only write to the header so your data will be preserved.  In
any case, make a backup first.

> i'm unsure how the emc san works in regards to "physical" disk cache;
> i'll have to do some research on that. to linux, it is just another
> patition (/emcpowerr1) mounted to /arcgis.

You'll have write cache on the EMC RAIDs.  Same thing with the battery
backup.

> /home resides on a local raid 1.
>
> plus, according to our oracle dba and our gis specialist, sde isn't
> that active of an application. i don't know why linux would cache this
> over anything else running on the server. a dozen or so san mounts
> running gis software and oracle databases and this is the only
> anomaly.
>
>
> thanks for the information and ideas!

I'd suspect something holding the directory inode open and/or FS
corruption because of this.

--dlloyd

_______________________________________________
discussion mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/discussion