BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] Reducing wear on SSD drives - worth the effort and, if so, how?
- Subject: [Discuss] Reducing wear on SSD drives - worth the effort and, if so, how?
- From: daniel at syntheticblue.com (Daniel M Gessel)
- Date: Thu, 1 Dec 2022 01:59:02 -0500
- In-reply-to: <20221130200031.GC3564@bladeshadow.org>
- References: <3cdb535c-a04a-fb96-7038-d0c0204af969@syntheticblue.com> <b943e5ff-e1e9-bc3a-0f06-3f0751cb595f@borg.org> <20221130200031.GC3564@bladeshadow.org>
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. >
- Follow-Ups:
- [Discuss] Reducing wear on SSD drives - worth the effort and, if so, how?
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] Reducing wear on SSD drives - worth the effort and, if so, how?
- Next by Date: [Discuss] Reducing wear on SSD drives - worth the effort and, if so, how?
- Next by thread: [Discuss] Reducing wear on SSD drives - worth the effort and, if so, how?
- Index(es):