Re: Trying to Simulate a disk failure for one of the disks used by ASM disk group

From: Seth Miller <sethmiller.sm_at_gmail.com>
Date: Thu, 28 Aug 2014 16:52:41 -0500
Message-ID: <CAEueRAWoZgwXs+w_z8b0PqvGCN5rCkdApkZQ0dkEuJNpUxOvwg_at_mail.gmail.com>



Hanan,

You can simply delete the virtual representation of the device from the scsi subsystem.

echo 1 > /sys/block/sdc/device/delete

Seth Miller

On Thu, Aug 28, 2014 at 1:34 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:

> doh. right you are.
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:
> oracle-l-bounce_at_freelists.org] *On Behalf Of *Matthew Zito
> *Sent:* Thursday, August 28, 2014 1:08 PM
> *To:* Mark W. Farnham
> *Cc:* hithanan_at_gmail.com; Chitale, Hemant K; ORACLE-L
>
> *Subject:* Re: Trying to Simulate a disk failure for one of the disks
> used by ASM disk group
>
>
>
> Remember, it's ASM, so there's no mounting or unmounting!
>
>
> Changing the permissions *might* work, but on Linux, since you still do an
> open() and get a file descriptor even when you're doing direct I/O, I think
> it would bypass it if the database is already running (since it already has
> a valid FD it's writing to/from).
>
>
>
>
>
>
>
> On Thu, Aug 28, 2014 at 1:03 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:
>
> If this is Linux or Unix, then probably umount followed by a mount
> readonly would do the trick if you’re writing to that disk at all.
>
>
>
> Possibly changing the permissions would intervene, but I think that varies
> about whether that will stop a running application that already has a file
> open.
>
>
>
> Heh. It was easier when there was a button on each drive you could toggle
> to make it read only.
>
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Aug 28 2014 - 23:52:41 CEST

Original text of this message