On Wed, Sep 16, 2026, at 15:47, Seif Allah Khalifa wrote: > Hi Ricardo, > > I appreciate your candid response regarding the support limitations. I fully > understand that we are operating outside the "standard" environment and that > the project cannot be expected to provide fixes for issues arising from such > setups. > > My interest, however, remains purely architectural. Even if the project > doesn't officially sanction it, I am interested in your technical perspective > on whether modern strategies effectively address the historical problems: > Separation of Concerns: By keeping Cyrus metadata (indexes/headers) on local > NVMe/SSD storage and only offloading bulk data (message bodies/attachments) > to NFS, does that mitigate the primary locking/concurrency dangers you > usually see?
Yep, it would. We don't lock spool files. You'd PROBABLY be OK with the cyrus.cache file on the external drive too. > Access Control: If we use a mail proxy to ensure that each mailbox is > accessed by only one server instance at a time, does this resolve the > concurrency conflicts that typically make NFS problematic for Cyrus? Don't even think about it like this. The index files are part of the data structure, you don't get to access the spool from somewhere that doesn't have them. "mail proxy" whatever - a particular path on the NFS server belongs to ONE server only. Obviously, you get to keep all the bits. But I don't see a reason why this wouldn't work. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected] ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/Tcf711fc6f0ce8498-M8d27ce7a60402923315856bd Delivery options: https://cyrus.topicbox.com/groups/info/subscription
