- Apr 22, 2016
- cPanel Access Level
- Root Administrator
Any update on this issue? I'm having the same problem.
Our Senior Technical Analysts do still need reproduction on this and I've pointed them in the direction of your ticket. They should be getting back to you soon!Hey guys,
I hate to say it but it looks like this issue has sprouted a new case CPANEL-31965 in which users are experiencing this behavior once again in v86 - I must have missed it when it was opened so I wasn't aware of it making a resurgence. @benito thank you for opening the ticket, the case is currently marked as Needs Reproduction and I've reached out to the product owner of that team to see if he needs anything from your server to reproduce this. We'll let you know what they come back with.
Right now the only workaround for this is to run the following:
But this is only temporary as if you access the default email account the issue will reoccur.Code:
/scripts/generate_maildirsize --confirm $USER
|Email Accounts†||16,499.26 MB|
* Contained in the mail directory.
|18,398.74 MB total disk space used.|
|10,240.00 MB quota limit (9,160.47 MB used).|
/usr/local/cpanel/scripts/generate_maildirsize --confirm $user
So you are saying that the issue of the default account total being incorrect is only happening on accounts added before the v82 fix and this problem no longer happens on new accounts. Meaning that the fix was put in place to stop it happening going forward but it won't resolve any existing accounts with this problem.From what I understand it appears that the issue is only affecting accounts added prior to the fix for the issue that was implemented in v82 - meaning that the fix is only resolving the issue on accounts added after the fix rather than resolving it for existing ones.
This makes sense for the purpose of disk quotas, as filesystem blocks cannot be shared by multiple files, so all of this space must be accounted to the system user which owns the file, even if the programs associated with the data aren't actually using that leftover space. This is a form of so-called "internal" fragmentation. If blocks could be shared by multiple files, and if these files could be owned by multiple system users, this would change the way the system would calculate disk quotas.
On the other hand, Dovecot cannot make assumptions about the underlying storage mechanism. Under Maildir or mbox, Dovecot on Linux could in theory ask the system about the number of filesystem blocks actually in use by particular files; however, the Dovecot software is not specific to Linux, so it does not make sense to make assumptions that its storage will only be allocated in blocks of a particular size. Moreover, this would add extreme amounts of complexity for little benefit. Therefore, it is much easier and makes more sense for it to account for usage in terms of the actual size of messages, regardless of how they are stored. For this reason, it is exceedingly unlikely that the usage reported by the system will exactly match the usage reported by Dovecot.
That said, this is not the only source of difference between the two figures at work here. Compression does not affect the size of messages, which never changes, even though it does change the amount of storage Dovecot needs for a given message. Additionally, compression at the point of storage is not a native capability of Dovecot and is instead implemented as a plugin. Changing Dovecot to be able to account for compression when accounting for usage against quotas likely would require additional complexity without sufficient benefit.
Both of these figures are correct, because they measure two quantities which are entirely different but related. The use of compression wildly exacerbates the difference, but even without use of compression, differences could be significant due to internal fragmentation. It just so happens that cPanel chooses to use one figure in certain places and the other figure in others.
Wow - who knew it could be so complicated? Sadly that leaves the end user in a very confusing situation. Like I said before - they don't care about the different ways that nerds can calculate usage - they just want to know how much disk space they are using.@4u123
I did some digging on the compression discrepancy and found the following very detailed explanation:
Thank you @cPRex for the update and I will wait until I hear from you on the next. The case was first reported in 2019, and now it's 2021 I believe this will be sorted this year yeah? Thank you again cpanel and we wish you a happy life. Charot.@iamkenrocks - I just checked the case and I see our developers are still working on it, although there isn't a fix available just yet.
|Thread starter||Similar threads||Forum||Replies||Date|
|C||SOLVED How to prevent storage provider can read my emails on cPanel?||1|
|V||Cpanel forwarded emails not getting in Gmail||5|
|I||In Progress CPANEL-42511 - email exim defer ( R=virtual_user T=dovecot_virtual_delivery defer (-1))||13|
|M||Using cPanel email or not for personal mailboxes of clients||5|
|H||SOLVED Problem sending mail between cPanel servers||3|
|SOLVED How to prevent storage provider can read my emails on cPanel?|
|Cpanel forwarded emails not getting in Gmail|
|In Progress CPANEL-42511 - email exim defer ( R=virtual_user T=dovecot_virtual_delivery defer (-1))|
|Using cPanel email or not for personal mailboxes of clients|
|SOLVED Problem sending mail between cPanel servers|