[Ocfs2-users] CRS/CSS and OCFS2

[Luis Freitas]

Sunil,

     You mean that even after the command completes writes will still be performed? Did some googling on this and seems that you are right. There is no way to force umount a filesystem on Linux, ugh. So one would need some way to check if the filesystem is still mounted before attempting to mount it, or some kind of SAN or device fencing.
   
Regards,
Luis

--- On Tue, 5/27/08, Sunil Mushran <Sunil.Mushran at oracle.com> wrote:
From: Sunil Mushran <Sunil.Mushran at oracle.com>
Subject: Re: [Ocfs2-users] CRS/CSS and OCFS2
To: lfreitas34 at yahoo.com
Cc: ocfs2-users at oss.oracle.com
Date: Tuesday, May 27, 2008, 7:46 PM

Lazy umount is not the same as forced umount. The processes
that have active descriptors will keep reading and writing to
the fs. The processes are not killed.

Luis Freitas wrote:
> Hmm,
>
>   There is a "lazy" umount:
>
>
>        -l     Lazy unmount. Detach the filesystem from the filesystem 
> hierar-
>               chy  now,  and cleanup all references to the filesystem 
> as soon
>               as it is not busy anymore. This option allows a âbusyâ 
> filesys-
>               tem to be unmounted.  (Requires kernel 2.4.11 or later.)
>
>   Not sure if this prevents writes on the filesystem after the umount 
> completes, or if there is some way to fence the device, so these 
> problems would need to be verified.
>
>   This is the way any other cold failover HA solution works, they dont 
> use cluster filesystems. If there is no way to force the filesystem to 
> be umounted or fence the device, it should be possible to configure 
> CRS to evict the primary node before the filesystem is mounted on the 
> secondary node. (Or use some external fence device, like a SAN switch 
> or power appliance).
>
>   Btw, is OCFS2 officially supported with Oracle 9i single instance 
> databases?
>
> Regards,
> Luis
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-users/attachments/20080527/38aab6ef/attachment.html