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, >> > *Cyrus <https://cyrus.topicbox.com/latest>* / Info / see discussions > <https://cyrus.topicbox.com/groups/info> + participants > <https://cyrus.topicbox.com/groups/info/members> + delivery options > <https://cyrus.topicbox.com/groups/info/subscription> Permalink > <https://cyrus.topicbox.com/groups/info/T31751150b37ea060-M05c1fa4191bf49649ff11f46> -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected] ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/T31751150b37ea060-M238ec66c3a9d05e138a6850c Delivery options: https://cyrus.topicbox.com/groups/info/subscription
