[mythtvnz] Database management

[Paul]

On 24/07/21 3:14 pm, Stephen Worthington wrote:
> On Sat, 24 Jul 2021 09:03:03 +1200, you wrote:
>
>>> And presuming that your new system has an SSD, then you probably want
>>> to TRIM the SSD more than once a week, as the MythTV database activity
>>> can use up quite a bit of the erased SSD space.  The default settings
>>> for Ubuntu's fstrim.service and fstrim.timer are to only run fstrim
>>> once a week.  So you should do:
>>>
>>> sudo edit fstrim.timer
>>>
>>> and put something like this in the systemd override file:
>>>
>>> [Unit]
>>> Description=Discard unused blocks once a day
>>>
>>> [Timer]
>>> OnCalendar=
>>> OnCalendar=daily
>>> AccuracySec=10m
>>>
>>> Or you could add the "discard" option to your SSD partitions in fstab.
>>> Or both, as I am now doing.
>> Hi ,
>>
>> Both my 16.04 and 20.04 systems use SSDs for the OS - storage is on HDD.
>>
>> I've read conflicting opinions on the use of discard.
> Yes, there are people out there who say that using discard will slow
> down write operations to the SSD.  My experience says that is not the
> case.  Their argument is that after any disk operation that decreases
> the size of a file, the file system then will need to tell the SSD
> with TRIM commands what storage has now been freed for re-use.  And
> that will slow things down.  However, I believe that the kernel
> authors would not have been so foolish as to have the system calls
> wait for that to happen before they return.  Instead, I think the TRIM
> operations will just be being queued up for the kernel to execute when
> it has idle time, and it will not hold up the software making the
> original file API call.  And in any case, SSDs these days have a queue
> of TRIM operations they keep internally, so the TRIM command will
> return immediately after the operation is queued by the SSD (just
> about instantly).  I started using discard after upgrading to 20.04
> and have not seen any performance changes, and now fstrim normally
> reports no blocks discarded, so it is working.  It is possible that
> older kernels may not have had such a good implementation of discard,
> so in 16.04 there might be a performance impact.  And if you have a
> very old SSD with a bad implementation of TRIM there could be an
> impact - I suspect that is where the warnings about using discard come
> from.
>
>> 'sudo edit fstrim.timer' in both my Ubuntu 21.04 desktop and 20.04 myth
>> TV box, results in: 'Error: no "edit" mailcap rules found for type
>> "cannot open `fstrim.timer' (No such file or directory)" ' What is the
>> name of the systemd override file you refer to? Cheers -Paul
> Sorry, that was a typo.  It should be:
>
> sudo systemctl edit fstrim.timer
>
> Systemd override files are found in directories under
> /etc/systemd/system.  The directory name for fstrim.timer would be
> /etc/systemd/system/fstrim.timer.d - any .conf files in that directory
> would be override files for fstrim.timer.  The directory and file will
> be automatically created by "systemctl edit", or you can create them
> manually.  I think that using systemctl edit means that systemd will
> know about the file immediately, but you may need to tell it to look
> with:
>
> sudo systemctl daemon-reload
>
> which you will certainly need to do if you create them manually.
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz at lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
>   

Hi

'sudo systemctl edit fstrim.timer' created     /etc/systemd/system/fstrim.timer.d/override.conf

The directory: '/fstrim.timer.d'     was created too, as it did not formerly exist.

I copied the contents of:   '/lib/systemd/system/fstrim.timer' into the empty 'override.conf' file and  altered them as below:

[Unit]
Description=Discard unused blocks once a day
Documentation=man:fstrim
ConditionVirtualization=!container

[Timer]
OnCalendar=daily
AccuracySec=10m
Persistent=true

[Install]
WantedBy=timers.target


Let me know if that's all ok.

Thanks
Paul