[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