Ocfs2 users - Dec 2006 - re: different availability requirements for multiple ocfs2 volumes?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks,
	quick question.
	In our current 3 node RAC cluster we have 2 ocfs2 volumes setup.
	We have a volume for sharing oracle CRS files (ocr.crs and vote.crs) and a 2nd
volume is going to be
	used to store backups and archivelogs. We will copy backups and archivelogs via
RMAN from the flash recovery
	area, onto this volume .. and eventually gets copied to another machine or
offsite storage.

	My concern is this ...

	The ocfs2 volume for the crs files needs to be highly available etc, and in the
event that there are problems,
	o2cb should do its thing.

	The backup volume availability requirements shouldn't be so strict because
if the volume is not available, I
	would just rather have my RMAN backup fail, and not have the machine reboot
	.. just because of this volume alone.


	My question is, is it possible to configure the "backup' volume is
such a way that the o2cb service will not
	reboot the machine in case that volume has problems?  Maybe disabling the
hearbeat for that volume ?

- -peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFgcM+oyy5QBCjoT0RArgRAJ0a9+/N8upHXrGt4s4xeUOzMHuxZACfSKmV
xVpd5edIX8Z0R5fWfVtWnK8=ngtE
-----END PGP SIGNATURE-----

Peter Santos wrote:
> 	The backup volume availability requirements shouldn't be so strict
because if the volume is not available, I
> 	would just rather have my RMAN backup fail, and not have the machine
reboot
> 	.. just because of this volume alone.
>
> 	My question is, is it possible to configure the "backup' volume
is such a way that the o2cb service will not
> 	reboot the machine in case that volume has problems?  Maybe disabling the
hearbeat for that volume ?
If you want the volume to be clustered, we would require a heartbeat.
But I do get your point and we are looking at avenues of reducing
the disk hb overhead by making it global, perhaps. But that's for 1.4.

For now, see if that volume has to be clustered. If not, maybe use ext3.

On a side note, we recently checked into mainline local mount functionality
that will allow users to mount ocfs2 volumes locally without any cluster
overhead.