gromox-mbsize(8)

💖 gromox-mbsize(8) 💖

Okay bestie, this is the gromox-mbsize(8) page from the Gromox admin reference. It’s giving “mailbox size detective” energy, and we’re about to break it all the way down. ✨

🌸 NAME 🌸

gromox-mbsize — Mailbox size analysis 🎀

✨ SYNOPSIS ✨

gromox-mbsize directory

🦋 DESCRIPTION 🦋

It shows a detailed view of how a mailbox size translates to on-disk usage. Explanation of the columns/rows follows, bestie — no cap, we’re going through every single one. 💅

⚠️ The reported numbers may slightly deviate from what du(1) would output, because mbsize does not count e.g. the config/ directory, tmp/ directory, sqlite auxiliary files, any other unreferenced attachments (cf. gromox-mbop(8) for the purge-datafiles command), and other stuff left there by outside actions. Periodt.

• Apparent size — This is the exact size of the object, or simply the sum of sizes of objects.
• On FS — This is the space that is used on the filesystem, and is subject to fs block sizes. Details about this behavior may be found on https://en.wikipedia.org/wiki/Block_(data_storage). As a result, the on-disk size may be larger than the apparent size. fs block size lore, iykyk.
• RFC5322/Mbox — For the sake of IMAP, RFC5322 copies of messages and some metadata is retained.
• RFC5322 Received — Applies to messages received via delivery(8gx).
• RFC5322 Sent — Applies to any other message.
• Body analysis — A set of 4 MAPI properties that usually get stored as files on disk rather than inside the sqlite database: PR_BODY, PR_HTML, PR_RTF_COMPRESSED and PR_TRANSPORT_MESSAGE_HEADERS. In gromox-mbsize, these are considered “body”.
• Attachment analysis — What it says. Not all MIME parts are or stay an attachment; for example, calendar items/meeting requests are usually converted to MAPI objects.
• Missing items/Apparent — The number of MAPI properties/attachments which have a dangling reference into the filesystem.
• Missing items/FS — The on-disk number of files that seem to be absent. This number can be lower than Apparent due to internal data deduplication that is transparent to MAPI/exmdb clients.
• Informational content — The logical amount of data that is represented by those four MAPI properties / by MAPI attachments.
• After deduplication — The logical amount of unique bodies/attachments.
• Dedup ratio/gains — For the “body” group, there are usually little gains to be observed in practice; bodies are just very unique. Messages like “test” are ironically the ones that benefit. Attachments dedup a little better, owing to many people sending/receiving redundant information, such as company logos. company logo spam finally does something useful 😭
• After compression — Besides deduplication, Gromox can also compress before data goes to disk. This is also the final form and so there is an apparent and an on-disk value. The on-disk value may be higher due to aforementioned filesystem block sizing.
• File compress ratio/gains — The earnings going from Dedup to Compressed.
• IFC compress ratio/gains — The earnings going from Informational Content to Compressed.
• MAPI reported sizes — The PR_MESSAGE_SIZE property of a store, folder, message, and the PR_ATTACH_SIZE property of an attachment, all give a close approximation to the amount of data needed to transfer the object(s) over a MAPI connection.
• NTS deviation — How much the Network Transfer Size is off from the on-disk size.
• Provisioning factor — The ratio between on-disk usage and the logical mailbox size reported inside MUAs.

👀 SEE ALSO 👀

• gromox(7)

That’s the whole page, bestie — every column, every caveat, every little storage gremlin accounted for. 🫶

Source/version: Gromox · Page: gromox-mbsize(8) · Date: not printed in the footer, and I refuse to make one up — no cap. 💅💖