Groups | Search | Server Info | Login | Register


Groups > uk.comp.os.linux > #23758

Re: TRIM

From Davey <davey@example.invalid>
Newsgroups uk.comp.os.linux
Subject Re: TRIM
Date 2025-09-17 15:54 +0100
Organization A noiseless patient Spider
Message-ID <10aei3k$399cl$1@dont-email.me> (permalink)
References (6 earlier) <10a99mt$20lgp$1@dont-email.me> <wwvikhhfrso.fsf@LkoBDZeT.terraraq.uk> <10adv4h$34co5$1@dont-email.me> <10ae150$34tq8$1@dont-email.me> <10aefkj$3881o$1@dont-email.me>

Show all headers | View raw


On Wed, 17 Sep 2025 15:12:35 +0100
Daniel James <daniel@me.invalid> wrote:

> On 17/09/2025 11:05, Davey wrote:
> > So, as one who knew nothing of trimming before this conversation
> > started, I am now as confused as ever as to what is the best
> > strategy to employ.  
> 
> That's partly because it's really difficult to give an unambiguously 
> correct answer. One size doesn't fit all.
> 
> > Should I set up a regular fstrim event, and if so, how frequently?
> > Once per week, once per month, or after a heavy data writing
> > session?  
> 
> Hard to say as we don't know the make/model of your SSD, how old it
> is, nor how full it is.
> 
> Modern SSDs are designed to work without TRIM ... nevertheless using 
> TRIM may be beneficial, and can help reduce SSD wear.
> 
> The benefit you'll get from TRIM is more if your SSD is close to
> full. This is because as the SSD fills up there are fewer empty pages
> to which the controller can write new data and so more work for
> garbage collection to do. Better-quality SSDs (newer designs, more
> reputable brands) have cleverer software that works better without
> TRIM, but that can also make better use of information from TRIM.
> 
> I would say that the "best" thing to do is to let the filesystem
> handle TRIM on-the-fly and forget about scheduled calls to fstrim.
> That's what I'm doing and nothing has bitten me yet ... but I may
> just be lucky. The SSD I use the most is a PNY device a year or so
> old so I expect it to be reasonably current and performant.
> 
> Older and cheaper SSDs are reported to experience problems when doing 
> TRIM on the fly, and if you have one of those then you would be
> better advised to use fstrim instead. Don't ask me which SSDs fall
> into this category because I can't give you a list.
> 
> The time that fstrim will be most beneficial is not after writing
> data to the SSD, it's after erasing data from the SSD ... so if you
> delete a lot of files, or if you edit a lot of files (so that a new
> version is created and the old one is deleted), there will be a lot
> of sectors to TRIM. Just writing new data to the disk doesn't create
> unused sectors, so TRIM won't help.
> 
> The general advice I see from people advocating the schedules use of 
> fstrim is to do it once a week, unless you have reason to believe
> that you need to do it more often. I know that doesn't help much.
> 
> fstrim doesn't take very long, and doesn't add to SSD wear, so
> there's no harm in running more often, it just won't add benefit.
> 
> One thing I would add: If you decide to turn on on-the-fly TRIMming
> (by adding "discard" to /etc/fstab) it's worth running fstrim once
> first, to bring the SSD up to date with what's actually in use in the
> flash memory, and what isn't. It should stay current by itself after
> that.
> 
> Does any of this help?
> 

Yes, it does, thank you. It sounds as though I might not bother unless
I see nearly full drives. Is an SSD still called a 'drive'?

My laptop is two and a half years old, the desktop is one year old. Both
have only SSDs. One of the laptop's SSDs became terminally full, which
prompted this whole saga. If you have followed this from the beginning,
the OS re-installation from scratch has gone great, and the secondary
SSD will be reinstalled soon. I have had a shedload of Real Life
getting in the way of my computing, so completion has been delayed.
Thanks.

-- 
Davey.

Back to uk.comp.os.linux | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Here we go again Davey <davey@example.invalid> - 2025-09-02 11:03 +0100
  Re: Here we go again Davey <davey@example.invalid> - 2025-09-03 08:57 +0100
    Re: Here we go again Daniel James <daniel@me.invalid> - 2025-09-03 16:49 +0100
      Re: Here we go again Theo <theom+news@chiark.greenend.org.uk> - 2025-09-03 17:21 +0100
        Re: Here we go again Davey <davey@example.invalid> - 2025-09-03 17:48 +0100
          Re: Here we go again Theo <theom+news@chiark.greenend.org.uk> - 2025-09-03 18:20 +0100
            Re: Here we go again Davey <davey@example.invalid> - 2025-09-03 20:10 +0100
            Re: Here we go again Davey <davey@example.invalid> - 2025-09-03 20:50 +0100
            Re: Here we go again Davey <davey@example.invalid> - 2025-09-04 11:35 +0100
              Re: Here we go again Daniel James <daniel@me.invalid> - 2025-09-04 17:30 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-04 19:52 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-05 23:49 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-08 11:50 +0100
                Re: Here we go again "Vincent Coen" <VBCoen@gmail.com> - 2025-09-08 16:11 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-08 17:28 +0100
                TRIM (Was: Here we go again) Daniel James <daniel@me.invalid> - 2025-09-15 16:00 +0100
                Re: TRIM (Was: Here we go again) Davey <davey@example.invalid> - 2025-09-15 17:30 +0100
                Re: TRIM Richard Kettlewell <invalid@invalid.invalid> - 2025-09-17 08:43 +0100
                Re: TRIM Daniel James <daniel@me.invalid> - 2025-09-17 10:30 +0100
                Re: TRIM Davey <davey@example.invalid> - 2025-09-17 11:05 +0100
                Re: TRIM Daniel James <daniel@me.invalid> - 2025-09-17 15:12 +0100
                Re: TRIM Davey <davey@example.invalid> - 2025-09-17 15:54 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-09 09:04 +0100
                Re: Here we go again "Vincent Coen" <VBCoen@gmail.com> - 2025-09-09 12:19 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-09 18:03 +0100
                Re: Here we go again "Vincent Coen" <VBCoen@gmail.com> - 2025-09-09 22:02 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-10 00:14 +0100
                Re: Here we go again -Update Davey <davey@example.invalid> - 2025-09-11 17:12 +0100
                Re: Here we go again -Update Davey <davey@example.invalid> - 2025-09-21 16:10 +0100
                Re: Here we go again -Update "Vincent Coen" <VBCoen@gmail.com> - 2025-09-22 01:41 +0100
                Re: Here we go again -Update Davey <davey@example.invalid> - 2025-09-22 09:29 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-10 12:43 +0100
                Re: Here we go again Theo <theom+news@chiark.greenend.org.uk> - 2025-09-08 21:33 +0100
              Re: Here we go again Daniel James <daniel@me.invalid> - 2025-09-04 20:07 +0100
                Re: Here we go again Davey <davey@example.invalid> - 2025-09-05 02:47 +0100
          Re: Here we go again Gordon <Gordon@leaf.net.nz> - 2025-09-03 23:46 +0000
            Re: Here we go again Davey <davey@example.invalid> - 2025-09-04 09:36 +0100
        Re: Here we go again Gordon <Gordon@leaf.net.nz> - 2025-09-03 23:31 +0000

csiph-web