Mailing List Archive

Database management
Hi All

What is the current set up for database optimisation?

In Mythbuntu 16.04 I selected "optimise database" in mythbuntu control
panel and a cron job was set up to run  optimize_mythdb.pl

I'm using the forked  Mythbuntu control panel in Xubuntu 20.04 ,but it
has no database set up functions.

Prior to creating a cron job to run optimize_mythdb.pl, I tried to run
optimize_mythdb.pl from the command line and I get:

Can't locate MythTV.pm in @INC (you may need to install the MythTV
module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0
/usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl
line 15.

Perl 5.30 is installed on my system

I found this thread:
https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894
<https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894>

Is the solution suggested advisable ,or are  there  other suggestions?

Thanks

Paul




_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Database management [ In reply to ]
On 23/07/21 3:43 pm, Paul wrote:
> Hi All
>
> What is the current set up for database optimisation?
>
> In Mythbuntu 16.04 I selected "optimise database" in mythbuntu control
> panel and a cron job was set up to run  optimize_mythdb.pl
>
> I'm using the forked  Mythbuntu control panel in Xubuntu 20.04 ,but it
> has no database set up functions.
>
> Prior to creating a cron job to run optimize_mythdb.pl, I tried to run
> optimize_mythdb.pl from the command line and I get:
>
> Can't locate MythTV.pm in @INC (you may need to install the MythTV
> module) (@INC contains: /etc/perl
> /usr/local/lib/x86_64-linux-gnu/perl/5.30.0
> /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30
> /usr/share/perl/5.30 /usr/local/lib/site_perl
> /usr/lib/x86_64-linux-gnu/perl-base) at
> /usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl
> line 15.
>
> Perl 5.30 is installed on my system
>
> I found this thread:
> https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894
> <https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894>
>
>
> Is the solution suggested advisable ,or are  there  other suggestions?
>
> Thanks
>
> Paul
>
Further searching on the web prompted me to check if libmythtv-perl was
installed - which it wasn't.

And in spite of things I read but didn't quite understand regarding @INC
being set at compilation , after installing libmythtv-perl ,to my
surprise, optimize_mythdb.pl  now seems to function - at least running
from the command  reports no errors.

Cheers

Paul

>
>

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Database management [ In reply to ]
On Fri, 23 Jul 2021 16:39:23 +1200, you wrote:

>
>On 23/07/21 3:43 pm, Paul wrote:
>> Hi All
>>
>> What is the current set up for database optimisation?
>>
>> In Mythbuntu 16.04 I selected "optimise database" in mythbuntu control
>> panel and a cron job was set up to run  optimize_mythdb.pl
>>
>> I'm using the forked  Mythbuntu control panel in Xubuntu 20.04 ,but it
>> has no database set up functions.
>>
>> Prior to creating a cron job to run optimize_mythdb.pl, I tried to run
>> optimize_mythdb.pl from the command line and I get:
>>
>> Can't locate MythTV.pm in @INC (you may need to install the MythTV
>> module) (@INC contains: /etc/perl
>> /usr/local/lib/x86_64-linux-gnu/perl/5.30.0
>> /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30
>> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30
>> /usr/share/perl/5.30 /usr/local/lib/site_perl
>> /usr/lib/x86_64-linux-gnu/perl-base) at
>> /usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl
>> line 15.
>>
>> Perl 5.30 is installed on my system
>>
>> I found this thread:
>> https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894
>> <https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894>
>>
>>
>> Is the solution suggested advisable ,or are  there  other suggestions?
>>
>> Thanks
>>
>> Paul
>>
>Further searching on the web prompted me to check if libmythtv-perl was
>installed - which it wasn't.
>
>And in spite of things I read but didn't quite understand regarding @INC
>being set at compilation , after installing libmythtv-perl ,to my
>surprise, optimize_mythdb.pl  now seems to function - at least running
>from the command  reports no errors.
>
>Cheers
>
>Paul

Mythbuntu Control Center has been forked to Mythbuntu Control Panel
and is now maintained again:

https://www.mythtv.org/wiki/Mythbuntu_Control_Panel

You normally want optimize_mythdb to be run daily - it should be put
in /etc/cron.daily. On Ubuntu, you can find the latest version from
the packages here:

/usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl

I prefer to backup my database daily also, so I copy
/etc/cron.weekly/mythtv-database to /etc/cron.daily and modify it to
backup to my backups directory on my big drive on my Windows PC, so I
get local backups weekly on the MythTV box and daily backups to the
Windows box. I use my modified version of mythconverg_backup.pl that
has an option to put the temporary .sql file in a different location
from the backup file. I put the temp file on my local NVMe SSD before
compressing it over the much slower network connection to my Windows
box to the mythconverg-*.sql.gz file, which makes the backup of my
massive database much faster.

http://www.jsw.gen.nz/mythtv/mythconverg_backup_jsw.pl

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Database management [ In reply to ]
On Fri, 23 Jul 2021 20:46:59 +1200, you wrote:

>On Fri, 23 Jul 2021 16:39:23 +1200, you wrote:
>
>>
>>On 23/07/21 3:43 pm, Paul wrote:
>>> Hi All
>>>
>>> What is the current set up for database optimisation?
>>>
>>> In Mythbuntu 16.04 I selected "optimise database" in mythbuntu control
>>> panel and a cron job was set up to run  optimize_mythdb.pl
>>>
>>> I'm using the forked  Mythbuntu control panel in Xubuntu 20.04 ,but it
>>> has no database set up functions.
>>>
>>> Prior to creating a cron job to run optimize_mythdb.pl, I tried to run
>>> optimize_mythdb.pl from the command line and I get:
>>>
>>> Can't locate MythTV.pm in @INC (you may need to install the MythTV
>>> module) (@INC contains: /etc/perl
>>> /usr/local/lib/x86_64-linux-gnu/perl/5.30.0
>>> /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30
>>> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30
>>> /usr/share/perl/5.30 /usr/local/lib/site_perl
>>> /usr/lib/x86_64-linux-gnu/perl-base) at
>>> /usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl
>>> line 15.
>>>
>>> Perl 5.30 is installed on my system
>>>
>>> I found this thread:
>>> https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894
>>> <https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894>
>>>
>>>
>>> Is the solution suggested advisable ,or are  there  other suggestions?
>>>
>>> Thanks
>>>
>>> Paul
>>>
>>Further searching on the web prompted me to check if libmythtv-perl was
>>installed - which it wasn't.
>>
>>And in spite of things I read but didn't quite understand regarding @INC
>>being set at compilation , after installing libmythtv-perl ,to my
>>surprise, optimize_mythdb.pl  now seems to function - at least running
>>from the command  reports no errors.
>>
>>Cheers
>>
>>Paul
>
>Mythbuntu Control Center has been forked to Mythbuntu Control Panel
>and is now maintained again:
>
>https://www.mythtv.org/wiki/Mythbuntu_Control_Panel
>
>You normally want optimize_mythdb to be run daily - it should be put
>in /etc/cron.daily. On Ubuntu, you can find the latest version from
>the packages here:
>
>/usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl
>
>I prefer to backup my database daily also, so I copy
>/etc/cron.weekly/mythtv-database to /etc/cron.daily and modify it to
>backup to my backups directory on my big drive on my Windows PC, so I
>get local backups weekly on the MythTV box and daily backups to the
>Windows box. I use my modified version of mythconverg_backup.pl that
>has an option to put the temporary .sql file in a different location
>from the backup file. I put the temp file on my local NVMe SSD before
>compressing it over the much slower network connection to my Windows
>box to the mythconverg-*.sql.gz file, which makes the backup of my
>massive database much faster.
>
>http://www.jsw.gen.nz/mythtv/mythconverg_backup_jsw.pl

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.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Database management [ In reply to ]
On 23/07/21 8:46 pm, Stephen Worthington wrote:
> On Fri, 23 Jul 2021 16:39:23 +1200, you wrote:
>
>> On 23/07/21 3:43 pm, Paul wrote:
>>> Hi All
>>>
>>> What is the current set up for database optimisation?
>>>
>>> In Mythbuntu 16.04 I selected "optimise database" in mythbuntu control
>>> panel and a cron job was set up to run  optimize_mythdb.pl
>>>
>>> I'm using the forked  Mythbuntu control panel in Xubuntu 20.04 ,but it
>>> has no database set up functions.
>>>
>>> Prior to creating a cron job to run optimize_mythdb.pl, I tried to run
>>> optimize_mythdb.pl from the command line and I get:
>>>
>>> Can't locate MythTV.pm in @INC (you may need to install the MythTV
>>> module) (@INC contains: /etc/perl
>>> /usr/local/lib/x86_64-linux-gnu/perl/5.30.0
>>> /usr/local/share/perl/5.30.0 /usr/lib/x86_64-linux-gnu/perl5/5.30
>>> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.30
>>> /usr/share/perl/5.30 /usr/local/lib/site_perl
>>> /usr/lib/x86_64-linux-gnu/perl-base) at
>>> /usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl
>>> line 15.
>>>
>>> Perl 5.30 is installed on my system
>>>
>>> I found this thread:
>>> https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894
>>> <https://lists.archive.carbon60.com/mythtv/users/628894?search_string=MythTV.pm;#628894>
>>>
>>>
>>> Is the solution suggested advisable ,or are  there  other suggestions?
>>>
>>> Thanks
>>>
>>> Paul
>>>
>> Further searching on the web prompted me to check if libmythtv-perl was
>> installed - which it wasn't.
>>
>> And in spite of things I read but didn't quite understand regarding @INC
>> being set at compilation , after installing libmythtv-perl ,to my
>> surprise, optimize_mythdb.pl  now seems to function - at least running
> >from the command  reports no errors.
>> Cheers
>>
>> Paul
> Mythbuntu Control Center has been forked to Mythbuntu Control Panel
> and is now maintained again:
>
> https://www.mythtv.org/wiki/Mythbuntu_Control_Panel
>
> You normally want optimize_mythdb to be run daily - it should be put
> in /etc/cron.daily. On Ubuntu, you can find the latest version from
> the packages here:
>
> /usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl
>
> I prefer to backup my database daily also, so I copy
> /etc/cron.weekly/mythtv-database to /etc/cron.daily and modify it to
> backup to my backups directory on my big drive on my Windows PC, so I
> get local backups weekly on the MythTV box and daily backups to the
> Windows box. I use my modified version of mythconverg_backup.pl that
> has an option to put the temporary .sql file in a different location
> from the backup file. I put the temp file on my local NVMe SSD before
> compressing it over the much slower network connection to my Windows
> box to the mythconverg-*.sql.gz file, which makes the backup of my
> massive database much faster.
>
> http://www.jsw.gen.nz/mythtv/mythconverg_backup_jsw.pl
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

Hi Stephen

Yes it is the forked version of MCP that I am using.

I'm using Mythwelcome to run autobackup.sh at shutdown each day a
recording happens and syncing the contents of /var/lib/db-backups with
an rclone script to a cloud storage directory.

Thanks

Paul


_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Database management [ In reply to ]
> 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.
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/


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.

'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
Re: Database management [ In reply to ]
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@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Database management [ In reply to ]
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@lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

Thanks Stephen

So what is your logic behind using both discard as well as a daily fstrim?

I will a look again for the .conf files - the corrected edit command
works in my desktop.

btw. My complete mythtv OS including database is only 13 GB on a 62 GB SSD.

Typically, I'm recording up to six or so programmes per day and deleting
them as soon as they have been viewed.

cheers

Paul


_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Database management [ In reply to ]
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@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




_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Database management [ In reply to ]
On Sun, 25 Jul 2021 11:45:51 +1200, you wrote:


>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

No, that is not the right way to do it. Override files do as the name
implies - any settings in an override file will override the matching
setting in the base file. So you do not copy the base file, just put
only the settings you are changing into the override file. So in this
case, the override file should only contain just what I posted.

There are some extra rules for override files to make them work
properly. Some settings can be used multiple times, so if you use
such a setting in an override file, it will be added to the list of
such settings that will be used. For such settings, if you want to
change existing settings in an override file, you have to tell systemd
to delete all the existing settings of that name and then add back in
the new ones that you want. You do that by using a setting name with
an = after it but nothing more on the line - that deletes all existing
settings of that name. Then after that line in the override file, you
put your new settings. So in my post, you will see the line
"OnCalendar=", which deletes all the existing OnCalendar settings,
followed by "OnCalendar=daily". So only "OnCalendar=daily" will be
use. With what you have done, you have added the "OnCalendar=daily"
setting to the existing "OnCalendar=weekly" setting, and now both will
occur. Which, fortunately, will not break anything, but is not ideal.

_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/
Re: Database management [ In reply to ]
On 25/07/21 3:51 pm, Stephen Worthington wrote:
> On Sun, 25 Jul 2021 11:45:51 +1200, you wrote:
>
>
>> 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
> No, that is not the right way to do it. Override files do as the name
> implies - any settings in an override file will override the matching
> setting in the base file. So you do not copy the base file, just put
> only the settings you are changing into the override file. So in this
> case, the override file should only contain just what I posted.
>
> There are some extra rules for override files to make them work
> properly. Some settings can be used multiple times, so if you use
> such a setting in an override file, it will be added to the list of
> such settings that will be used. For such settings, if you want to
> change existing settings in an override file, you have to tell systemd
> to delete all the existing settings of that name and then add back in
> the new ones that you want. You do that by using a setting name with
> an = after it but nothing more on the line - that deletes all existing
> settings of that name. Then after that line in the override file, you
> put your new settings. So in my post, you will see the line
> "OnCalendar=", which deletes all the existing OnCalendar settings,
> followed by "OnCalendar=daily". So only "OnCalendar=daily" will be
> use. With what you have done, you have added the "OnCalendar=daily"
> setting to the existing "OnCalendar=weekly" setting, and now both will
> occur. Which, fortunately, will not break anything, but is not ideal.
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz@lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/

Thanks Stephen

Correcting it now.

Cheers


_______________________________________________
mythtvnz mailing list
mythtvnz@lists.ourshack.com
https://lists.ourshack.com/mailman/listinfo/mythtvnz
Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/