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 [email protected] CYRUS [1] / Info / see discussions [2] + participants [3] + delivery options [4] Permalink [5] Links: ------ [1] https://cyrus.topicbox.com/latest [2] https://cyrus.topicbox.com/groups/info [3] https://cyrus.topicbox.com/groups/info/members [4] https://cyrus.topicbox.com/groups/info/subscription [5] https://cyrus.topicbox.com/groups/info/T31751150b37ea060-M238ec66c3a9d05e138a6850c ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/T31751150b37ea060-Ma5546ee498c1b764b5685a8e Delivery options: https://cyrus.topicbox.com/groups/info/subscription
