Will linking the clock file to an in-memory file lower the wear on the SD card?

Question

I use systemd-timesyncd, which writes a status (probably) to a file at every synchronization. As the Arch documentation mentions,

The service writes to a local file /var/lib/systemd/clock with every synchronization. This location is hard-coded and cannot be changed.

The file is actually different on a RPi but the problem is the same.

On the other hand, /dev/shm is an in-memory filesystem, so would linking the status file to a file over there lower the SD card wear?

root@rpi1 /v/l/p/s/timesync# pwd
/var/lib/private/systemd/timesync
root@rpi1 /v/l/p/s/timesync# ll
total 0
lrwxrwxrwx 1 root root 14 Jan  1 00:50 clock -> /dev/shm/clock

The status above is after the creation of the link and restart of the service.

Since systemd-timesyncd has not recreated the file (and remove the link) I would be inclined to think that this could be a reasonable workaround for the often-written-to file on the SD card.

Answer 1

Do NOT WASTE YOUR TIME worrying about SD card wear!

This is one of the urban myths. Any decent card will have wear levelling.

If you did REALLY want to minimise writing to the card this file would be one of those LEAST to be concerned about. (There are stacks of logs written.)

PS If you DO want to wear out Flash memory, I can show you how to do this in ~24hours, but you have to really try.

PPS /var/lib/systemd/clock is never ACTUALLY written; it is just an entry in the directory, which is buffered, and only occasionally written to disk, along with other filesystem changes.