[Discuss] Reducing wear on SSD drives - worth the effort and, if so, how?

Daniel M Gessel daniel at syntheticblue.com
Thu Dec 1 01:59:02 EST 2022


There's definitely a tradeoff.

My systems are all part of my grand adventures where I make different 
choices than I would for a system used by others for community, 
commercial or mission critical purposes.

Heck, I'd do it differently even if I were just maintaining a system for 
my wife's use (she uses Windows for work and on-and-off tries to justify 
a Mac for personal use, but never quite indulges).


On 2022-11-30 15:00, Derek Martin wrote:
> On Fri, Nov 18, 2022 at 11:05:52AM -0800, Kent Borg wrote:
>> I put /tmp and /var/tmp in RAM disks, figuring that would move some
>> background activity off the SSD.
> Rich already pointed out a potential downside of this... here are a
> couple other points to consider, which you might not have:
>
>   - /tmp and /var/tmp have different intended use cases; /var/tmp is
>     meant for temporary files that should survive a reboot.  They won't
>     on a ramdisk, so if you have applications using it properly, they
>     will be affected.  What that means in practice will obviously
>     depend on the application...
>   
>   - You never really know what applications are using /tmp or /var/tmp,
>     and how much storage they are using.  An example from--wow, 21
>     years ago--when I was sysadmin at MCL (I'm going to assume my
>     memory is accurate despite the time frame, but offer the caveat
>     that it may not be):
>     
>     The mail server (which was set up before they hired professional
>     sysadmins, for whatever that's worth) ran UW IMAP.  The size of
>     /tmp was some small-but-seemingly-reasonable size--I don't remember
>     exactly but say 200MB or something like that (remember, 20+ years
>     ago). After a while people started to experience random failures
>     with their IMAP folders, and it took us some time to figure out
>     why...  What actually was happening was that when you expunge
>     messages from your folder, the imap server was creating a temporary
>     copy of your folder in /tmp, and then copying it back to where it
>     was supposed to live.  The filesystem was not sized appropriately
>     for that use case, and we ended up needing to make it much larger
>     to accommodate it.
>
>     Were I to have been the one to set up the server, I would've
>     allocated /tmp to be significantly larger than it was, but still
>     not likely large enough to accommodate this usage, having been
>     unaware of this at the time.
>
>     Point being, if you're running some application like this that
>     consumes much more temporary storage space than you anticipate, it
>     will exacerbate the issue Rich pointed out, and also increase the
>     likelihood you'll experience OOM situations causing your other apps
>     (or the same one) to crash randomly if you don't have enough RAM +
>     swap to cope.
>



More information about the Discuss mailing list