MESSAGE quota resource implemention
brong at fastmail.fm
Fri Sep 2 02:22:43 EDT 2011
On Fri, Sep 02, 2011 at 09:37:24AM +1000, Rob Mueller wrote:
> >Actually, really I'd like to create a new UNIQUEID - and store
> >all the files in paths based on uniqueid rather than on folder
> >name. This would not only mean renames could be fast and
> >atomic, but that delayed delete would be fast. The downside is
> >a more opaque filesystem layout. Oh, another upside - file path
> >limitations don't exist so much any more.
> While UNIQUEID is nice, the opaqueness is annoying. Personally, I
> liked the idea that we talked about a while back which I think was:
I still have a patch somewhere that does that.
> So you end up with every folder for a user in one dir. This solves
> the current messy handling of sub-dirs (eg currently you have to
> create the intermediate dir /abc/ even though there's no entry in
> mailboxes.db for it), and makes renaming any folder very cheap still
> (because you can do it with a single dir rename, rather than having
> to move each message file), but you don't go completely opaque.
It does give you a 256 character folder tree limit on many operating
> Delete handling is still easier, just rename to
> DELETED.$oldname.$UNIQUEID or something like that, because it's
> cheap to rename anyway.
Sorry, make that 239, once you make space for timestamps and dots.
> Of course it means re-organising folder layout for every
> installation out there, but maybe we need to bump major versions
> anyway, cyrus 3.0 here we come :)
tools/rehash - I have one of those that can handle this plus all the
other existing formats as well. It's on a git branch somewhere.
More information about the Cyrus-devel