[Linux-cluster] IMAP server clustering ...

Michael Gale michael.gale at utilitran.com
Mon Nov 1 18:26:07 UTC 2004


That makes more sense ... thanks for the info and in helping me avoid 
corrupted data.

Michael.


linux-cluster at spam.dragonhold.org wrote:
> On Mon, Nov 01, 2004 at 10:25:03AM -0700, Michael Gale wrote:
> 
>>I was reading up on Courier IMAP which use dot-locking with support NFS 
>>mounted maildirs.
>>
>>So would that application not take care of the locking ?
> 
> 
> No, it's operating at the wrong level.
> 
> (starting from nothing cached)
> 
> Think about it this way - you create a new file on the disk (say the lock file).  The other
> machine then tries to access the directory.  It scans down from the root of the partition
> (successfully, since nothing has changed), and gets to the directory.  This finds the
> lockfile.
> 
> So far so good.
> 
> Now the 1st machine deletes the lockfile.  However, the 2nd machine still has this cached as
> locked - and therefore doesn't notice.
> 
> 
> --
> 
> Other example.
> 
> Both machines read the directory (and it's not locked).  Next machine 1 locks it.  Even if
> reiserfs writes this lock back to disk (which it will eventually), the 1st machine doesn't
> know, since it still has a cached version of the directory which shows that the file doesn't
> exist.  Now both can lock (successfully as far as they are concerned).
> 
> 
> --
> 
> Final example.
> 
> Machines 1&2 both have the lock.  One deletes a file, and updates the disk.  The 2nd adds a
> file, and then updates the directory with it's version (which still has the first file in
> it).
> 
> This means you've got the file pointing to the blocks where it exists, but the blocks have
> been freed.
> 
> If you do that with another directory (create a new IMAP folder) rather than file, and it
> gets even worse - the machine that didn't create it won't know that those inodes are a
> directory, so will happily then write a file over it.
> 
> --
> 
> If this doesn't make sense (quite possible, I've not worked through the examples properly),
> just work it through on paper.  Remember that the machines have no reason to doubt their
> cached copy of the data, and they will cache as much as possible.
> 
> Go through what could happen from a starting point of the disk & caches agreeing,
> remembering that not only is read data cached, data is not written back out immediately.
> 
> 
> Graham
> 
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-cluster
> 
> 
> 
> 

-- 
Michael Gale
Lan Administrator
Utilitran Corp.

We Pledge Allegiance to the Penguin




More information about the Linux-cluster mailing list