Re: Can LOCK_NOLOCK be used in this situation?

On Fri, Apr 15, 2005 at 10:24:44AM -0700, Srini Sankaran wrote:
...
> A few minutes to hours later, node 2 might take over the read / write 
> responsibilities for "/big/a", and node 1 might move over to "/big/b", 
> etc.
...
> So, my question is: Can I simply use LOCK_NOLOCK in this situation and 
> avoid any lock server? Maybe the answer is no because the documentation 
> warns "Do not allow multiple nodes to mount the same file system while 
> LOCK_NOLOCK is used. Doing so causes one or more nodes to panic their 
> kernels, and may cause file system corruption".
> 
> I am still asking the question because of this partitioned file system 
> access characteristic of my application. Is this warning still valid if 
> I can guarantee that no two files or directories will be accessed by 
> two different nodes simultaneously? If I can't do LOCK_NOLOCK, is there 
> any other idea I can use here?

Nolock won't work here.  Even if the directory tree is partitioned between
nodes, the allocation bitmaps aren't.  Allocate enough and you'll see
contention there.  And without locking, you'll see corruption there too.

You also need locking to manage the transitions when a machine switches
directories.  Caches need to be flushed and invalidated.  The locking
makes that happen.

If you're reluctance to use locking is just because you don't want
dedicated GULM lock servers, you might want to try the DLM instead.

-- 
Ken Preslan <kpreslan@xxxxxxxxxx>