Re: Suggestions for Cyrus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Bron!!!

But exists too the singleinstancestore too parameter... wasn't it?. Ohhh.. I see... perhaps with that message uuid (and linking it with a database to X folders of different users), you can just say, this folder is not present anymore (because even you don't have folders really in the filesystem...?)... and later you remove with cyr_expire perhaps?.


Cheers!



 


El 2022-05-11 17:07, Bron Gondwana escribió:

The good news with the very latest Cyrus (pre-release git master) is that we now store files on disk by uniqueid rather than folder name, which means that there are no big create/deletes required for a folder rename (including a folder delete).
 
This will be present in a release eventually!
 
Cheers,
 
Bron.
 
On Tue, May 10, 2022, at 19:33, egoitz via Info wrote:

Hi there!


Please forget this email.


I have arrived to the conclusion that makes you notice that it's not possible due that a delayed delete, it's no more than a rename finally. And in a rename... you need to end up by removing the source folder, for being able to recreate a new one with the same name... and no... in the users hierarchy you can't use something as mboxname_todeleted for generating a suffix because you don't really know, what kind of name a user could make use for creating a imap folder.


About the io rate limit, non sense too due to Cyrus seems not to fork in that kind of operations and you can always limit the maxlogins_per_user parameter..


Sorry for the noise... really,


Cheers,

 


El 2022-05-06 12:21, egoitz via Info escribió:

Good morning,


We are suffering some performance issues with some new ssd disks we are testing. We suffer in performance, due to write amplification and trims.

Having seen that, I have been thinking perhaps a couple of things would be very useful in Cyrus. We use delete mode delayed and that's nice for messages, but does not help when you remove for instance one big folder with 50.000 messages each. I say it because for that purpose Cyrus creates the entire hierarhy under DELETED again. When say it creates I mean it copies first whole deleted folders, then deletes them from original place. One extremely nice thing that Cyrus has, is the possibility of removing content at cyr_expire running time... nightly... it's a big pity not to be able to do this same with a whole deleted folder.

I think that perhaps a new folder/mailbox state could be created for avoid listing that folder in a LIST or LSUB.... Later cyr_expire to check the existence of folders in that state (folder removed) and then to be removed (but at night... when cyr_expire runs...).

Another idea, I think it would be very useful is, when a non admin user is copying a very big amount of data, to be possible to rate limit the total amount of disk io at which that copy could be done. I think that could be extremely useful too.

If is nothing similar created (of both things) do you think too could be useful?. I could try to propose to my bosses working on it and later to share this work with Cyrus community :) . What do you think about it?.


Cheers,

 
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@xxxxxxxxxxxxxxxx
 
 

[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux