2.4.6 reconstruct: timestamp mismatch which doesn't go away
brong at fastmail.fm
Wed Jan 19 05:30:24 EST 2011
On Wed, Jan 19, 2011 at 07:36:17AM +0100, Simon Matter wrote:
> I've done some upgrades from 2.3.16 to 2.4.6 and it seems sometimes a
> reconstruct is the only way to get a mailbox work after upgrade. While
> running reconstruct two things have shown up which I have not seen wirh
> older releases:
> 1) on a mailbox which was used by a client reconstruct was just sitting
> there doing nothing. Seems like it was waiting for a lock to be freed?
> After terminating the client reconstruct would immediately resume it's
> work. Maybe that's expected, I'm just wondering how those with large
> number of users will reconstruct while the server is online? I mean, IIRC
> with older releases it was always possible to do a full reconstruct while
> users had access to their mailboxes. Is it not possible that way anymore?
Do you have any suggestion for how that could be done safely? The
reconstruct requires a write lock on the mailbox while it does its
work. The reconstruct will only block while the client has the mailbox
actively locked - which should only be while it's performing work that
requires a lock. So not while it's just idle.
> 2) I got some "timestamp mismatch" errors while reconstructing my own
> mailbox. I've read here
> that this should happen only once because the timestamp of the file should
> be corrected. That doesn't seem to be true in my case. Any ideas why?
Do you get them again and again while reconstructing the same mailbox?
That's very odd. Are the permissions on the file correct? I'm not sure
if we check that the utime command worked - maybe we should.
More information about the Info-cyrus