X-Status flag, reconstruct and a suggestion

[Rob Siemborski]

On Sat, 4 Oct 2003, Diego Rivera wrote:

> How about adding a second text file a-la "34.status" which ONLY contains
> the X-Status flag?  If the file exists, reconstruct could leverage it...
>
> My line of thinking is this: if a catastrophe prevents me from using the
> DBs, or the DBs are partially corrupted for a group of users who also
> happen to have a lot of e-mail, the X-Status information lets me restore
> the entirety of the mailbox status info as it was before the failure,
> rather than have all the statuses reset due to the failure.

What's to prevent the same catastrophe that destroyed your databases from
having destroyed the "spare" status information?

> Note that I'm thinking of ALWAYS replacing the contents of the status
> file, rather than trying to edit it.  Also, in case the file is lost for
> a particular message it's no big deal that THAT particular message's
> status gets reset, but it helps in keeping the bulk of the mailbox's
> statuses available for a good recovery - which would be the goal.

This is still a significant perforamce hit.

Think what happens if you issue

STORE 1:1000 (FLAGS (\Deleted))

That's atleast 1000 each of open() write() fsync() and close() calls.
That's a significant increase from just modifying a single file (even if
it does mean modifying it in 1000 places).

I just can't see the benefit given that if the database is corrupted
(which is rare -- as opposed to flag changes which are *frequent*), the
rest of your data is suddenly suspect anyway.

Additionally, one of the reasons \Seen state is currently per-user instead
of stored with the mailbox is because in shared mailbox situations it had
become a bottleneck. I wouldn't want to see us return to that situation.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper