Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

I install SSDs and warn users not to defrag, since it causes unnecessary writes, wearing the SSD needlessly. But thunderbird tells people to compact their fol

  • 2 replies
  • 1 has this problem
  • 1 view
  • Last reply by diacad

more options

Thunderbird asks users to "compact" its folders periodically - assuming this is analoguos to defragmentation, requiring many unnecessary writes, is Thunderbird thus detrimental to SSDs? I would like to see some discussion of this.

Thunderbird asks users to "compact" its folders periodically - assuming this is analoguos to defragmentation, requiring many unnecessary writes, is Thunderbird thus detrimental to SSDs? I would like to see some discussion of this.

Chosen solution

Thunderbird stores messages one after the other in a large file (this is the so-called mbox mail storage system). So each folder in Thunderbird represents a large file in the file system. Each message has status flags that determine if it has been read or deleted, amongst other possibilities. So those messages which have been deleted, whether by the user or by some housekeeping are marked with a status value that says "don't show me in the message list". But the bytes are still there occupying disk space.

Compacting is, in part, the process of reading and re-writing that file, omitting the deleted items. I wouldn't call it defragging, but since we are not deleting files per se, we can't rely on the filesystem's garbage collection/journalling or whatever to be able to recover the space occupied by these deleted-but-not-yet-removed messages.

If we don't compact, then deleted messages will never be removed and your free disk space will dwindle to nothing. Compacting is a necessary evil.

I suspect you are being over cautious. SSDs are now replacing traditional rotating platters and so must be considered by the manufacturers to be capable of a great many more write cycles than has traditionally been the case with flash and related technologies.

For myself, given the luxury of both HDD and SSD, I'd put the Thunderbird program on the SSD and its profile (aka its message store) on the HDD. If you offer your customers a HDD/SSD combination, I'd urge you to do the same. And even if there is only one disk, I'd partition it for OS vs data and put the profile into the data partition. This means that the user's data has a better chance of surviving an OS rebuild.

Thunderbird does offer a way out of this, but…

It is possible to not use mbox and use instead maildir, where messages are stored as discrete files (one message per file). So in this model, if you delete a message, it can be really deleted and the filesystem can recover the space it releases. I'm sure it's not quite as simple as that, as you still have the option to move a deleted message to Trash and subsequently un-delete it, or indeed, delete it permanently. So, deleting doesn't necessarily immediately release space. And moving a message will always involve some re-writing somewhere, even if the data remains in place.

One major downside is that maildir in Thunderbird is still considered experimental. So support in the case of a nasty incident such as major data loss might be hard to find. Another downside is that it's not quite the maildir known by Unix folk, so falls a little short of their particular expectations.

I am using maildir myself and have done so for a couple of years and no mishaps (yet!)

Read this answer in context 👍 1

All Replies (2)

more options

Chosen Solution

Thunderbird stores messages one after the other in a large file (this is the so-called mbox mail storage system). So each folder in Thunderbird represents a large file in the file system. Each message has status flags that determine if it has been read or deleted, amongst other possibilities. So those messages which have been deleted, whether by the user or by some housekeeping are marked with a status value that says "don't show me in the message list". But the bytes are still there occupying disk space.

Compacting is, in part, the process of reading and re-writing that file, omitting the deleted items. I wouldn't call it defragging, but since we are not deleting files per se, we can't rely on the filesystem's garbage collection/journalling or whatever to be able to recover the space occupied by these deleted-but-not-yet-removed messages.

If we don't compact, then deleted messages will never be removed and your free disk space will dwindle to nothing. Compacting is a necessary evil.

I suspect you are being over cautious. SSDs are now replacing traditional rotating platters and so must be considered by the manufacturers to be capable of a great many more write cycles than has traditionally been the case with flash and related technologies.

For myself, given the luxury of both HDD and SSD, I'd put the Thunderbird program on the SSD and its profile (aka its message store) on the HDD. If you offer your customers a HDD/SSD combination, I'd urge you to do the same. And even if there is only one disk, I'd partition it for OS vs data and put the profile into the data partition. This means that the user's data has a better chance of surviving an OS rebuild.

Thunderbird does offer a way out of this, but…

It is possible to not use mbox and use instead maildir, where messages are stored as discrete files (one message per file). So in this model, if you delete a message, it can be really deleted and the filesystem can recover the space it releases. I'm sure it's not quite as simple as that, as you still have the option to move a deleted message to Trash and subsequently un-delete it, or indeed, delete it permanently. So, deleting doesn't necessarily immediately release space. And moving a message will always involve some re-writing somewhere, even if the data remains in place.

One major downside is that maildir in Thunderbird is still considered experimental. So support in the case of a nasty incident such as major data loss might be hard to find. Another downside is that it's not quite the maildir known by Unix folk, so falls a little short of their particular expectations.

I am using maildir myself and have done so for a couple of years and no mishaps (yet!)

more options

Zenos - Thanks for your discussion - I am sure other people are concerned about this. Maybe the write "wear out" phenomena will disappear as SSDs advance - it is still a fairly new and developing technology.