On 18.11.2007, at 1.52, Trond Myklebust wrote:
>> close()+open() would have been difficult to handle because open() can
>> fail, but looks like opening another file descriptor and closing it
>> works just as well. Also looks like it works for flushing
>> directories'
>> attribute cache (which doesn't seem to work with FreeBSD though).
>>
>> There's one potential problem with closing a file descriptor
>> though. It
>> loses all fcntl locks for that file from all fds. I'm not sure if
>> this a
>> problem for me though.
>
> Right. I understood that you were not using fcntl() locks. Those
> will in
> any case ensure cache revalidation, so you wouldn't have to use
> anything
> else.
That assumes that locks are used in a typical "read lock" and "write
lock" way. Dovecot currently does, but not necessarily in future. For
example UW-IMAP's mbx format requires grabbing a shared lock when the
mailbox is opened and keeping it until the mailbox is closed. The
shared lock prevents messages from being deleted from the file, but
it doesn't prevent message flag updates or appending new messages to
the file. To see if there are new messages would require flushing
attribute cache to get the file size updated, but close+open wouldn't
work because it would drop the shared lock and drop the guarantee
that no messages get deleted while the mailbox is open.
> Again, you can use the close-to-open trick of simply reopening the
> file
> whenever you need to revalidate the data cache.
>
> The problem, however, is that on the most common Linux filesystems
> (ext2/ext3, reiserfs,...) the time resolution on the mtime is 1
> second.
> If your NFS server is running one of those filesystems, then the data
> cache revalidation may fail to detect a write that happens within 1
> second of the previous write.
Most people are using NetApps, and they also seem to have 1 second
resolution (at least the one I just tested had). So this isn't a
solution. "Let's hope that there are no writes less than 1 second
apart" isn't really a solution either. People like their mailboxes
uncorrupted.
On Sun, 2007-11-18 at 02:26 +0200, Timo Sirainen wrote:
> Most people are using NetApps, and they also seem to have 1 second
> resolution (at least the one I just tested had). So this isn't a
> solution. "Let's hope that there are no writes less than 1 second
> apart" isn't really a solution either. People like their mailboxes
> uncorrupted.
No. NetApp filers and WAFL have nanosecond resolution. They should be
fine.
Cheers
Trond
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs