On Wed, 2006-04-26 at 00:36 +1000, grant beattie wrote:

On Tue, Apr 25, 2006 at 05:33:10PM +0300, Timo Sirainen wrote:

...

I've finally managed to run Dovecot without errors in two computers with maildir and indexes stored in NFS. I added a page to wiki about this:

http://wiki.dovecot.org/NFS

I presume the comments about locking only relate to mbox storage (and the indexes), not maildir, as maildir is lock free and always NFS-safe by design.. right?

No. Maildir is lockless only if

a) You don't really care about concurrent mailbox access. It works most of the time, as long as you're not doing heavy concurrent accessing. I'm not a fan of this solution, but that's how pretty much all other maildir MUAs work.

b) You're using an operating system and/or filesystem which never skips files in readdir() system call while files are being added/removed/renamed. I don't know of any such OS/FS.

So, Dovecot locks all maildir accesses.

Anyway, the comments about locks only mean index file locking. Those are the same with all mail storages.

On Wed, 2006-04-26 at 13:26 +0200, Miquel van Smoorenburg wrote:

On Tue, 2006-04-25 at 17:33 +0300, Timo Sirainen wrote:

...

I've finally managed to run Dovecot without errors in two computers with maildir and indexes stored in NFS. I added a page to wiki about this:

http://wiki.dovecot.org/NFS

Suggestions how to keep attribute cache enabled but to allow Dovecot to specifically request not to use a cached value (when it's important) would be welcome.

Timo, you use Debian - if you have liblockfile-dev installed, the manpage of lockfile-create(3) has a section called "REMOTE FILE SYSTEMS AND THE KERNEL ATTRIBUTE CACHE".

See the part on chmod() there on how to invalidate the attribute cache for one file on Linux.

Manpage is attached.

I'be just tested on Linux 2.6 and freebsd 4.10 some more. It appears that the chmod trick doesn't work on freebsd, and freebsd 4.10 doesn't have support for fntl locking either AFAIK.

However both of them invalidate the attribute cache of a file directly when you do fd = open("file", O_WRITE|O_APPEND); which makes sense. Perhaps you can use that as a semi-portable way to invalidate a files attribute cache.

Mike.

On 8.12.2006, at 0.39, Richard Laager wrote:

...

Timo, you use Debian - if you have liblockfile-dev installed, the manpage of lockfile-create(3) has a section called "REMOTE FILE
SYSTEMS AND THE KERNEL ATTRIBUTE CACHE".

Timo,

I swear I read somewhere that you had implemented something like this, but I can't find it. Is it still necessary to disable the attribute cache to put indexes in NFS?

I intended to implement it, but I've still not gotten around to doing
it. So yes, it's still needed.

If so, do you have any idea how much of a performance impact that
is vs. clearing the attribute cache as needed?

Probably pretty bad.

Any idea what it would cost to have you code this feature?

Maybe a couple of day's work, but I'm not sure how much better it
would make the performance compared to disabling the attribute cache
completely. Might be just as bad..