[arch-general] ssd trim using fstrim.service and fstrim.timer
Francis Gerund
ranrund at gmail.com
Mon Dec 28 04:14:46 UTC 2015
I hope this doesn't sound stupid, but I'm totally new to systemd. And I am
not familiar with systemd-journal. So, I did:
systemctl start fstrim.service
It seems to have worked. I got:
systemctl status fstrim.service
fstrim.service - Discard unused blocks
Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor
preset: disabled)
Active: inactive (dead) since [redacted]; 3min 50s ago
Process: 1200 ExecStart=/sbin/fstrim -a (code=exited, status=0/SUCCESS)
Main PID: 1200 (code=exited, status=0/SUCCESS)
So thanks for the reply.
On Sun, Dec 27, 2015 at 10:18 PM, Leonid Isaev <
leonid.isaev at jila.colorado.edu> wrote:
> On Sun, Dec 27, 2015 at 09:45:27PM -0500, Francis Gerund wrote:
> > Per the Arch wiki SSD page, I just enabled sysctl fstrim.timer, and then
> > rebooted. I did not "enable" fstab.service. Now fstrim.timer is loaded,
> > and active (but "waiting") and fstrim.service is loaded, but inactive.
> And
> > the time stamp file the wiki mentions has a "0" size.
>
> In /var/lib/systemd/timers? They all have zero size, it's their timestamp
> what
> matters.
>
> > So, do I have to wait (A WEEK!) to see if it works, or can I somehow now
> > run fstrim.service manually to at least get it done once?
>
> fstrim.service most likely ran on-boot, silently, so you haven't noticed.
> If
> you use systemd-journal, check it, otherwise just start fstrim.service w/o
> enabling it (or run its ExecStart cmdline).
>
> > Note: I could just add "discard" to /etc/fstab, but wouldn't that wear
> out
> > the SSD faster than periodic trimming?
>
> I don't know precise numbers, but IME none of those made a difference
> performace-wise. I'd say if SSD wear is a problem (i.e. if you estimate it
> within expected usage time of the device), just switch to a HDD.
>
> HTH,
> --
> Leonid Isaev
> GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
> C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
>
More information about the arch-general
mailing list