Mailing List Archive

maria db
Re: maria db [ In reply to ]
On Fri, Jun 2, 2023 at 6:54?AM James <jam@tigger.ws> wrote:

> There is quite a lot of discussion on why not to use btrfs with maria
> https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58
>

There's a few different solutions if you already have the files created
since the +C must be done at creation.

My method is to:
mv <file> <file>_backup
touch <file>
chattr +C <file>
dd if=<file>_backup of=<file>

You can add bytesize (bz=1M) or similar to speed it up. I did this with a
1TB blockchain file successfully.

Thanks,
Richard
Re: maria db [ In reply to ]
> On 2 Jun 2023, at 8:08 pm, Richard Shaw <hobbes1069@gmail.com> wrote:
>
> On Fri, Jun 2, 2023 at 6:54?AM James <jam@tigger.ws <mailto:jam@tigger.ws>> wrote:
> There is quite a lot of discussion on why not to use btrfs with maria
> https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58 <https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58>
>
> There's a few different solutions if you already have the files created since the +C must be done at creation.
>
> My method is to:
> mv <file> <file>_backup
> touch <file>
> chattr +C <file> <>
> dd if=<file>_backup of=<file>
>
> You can add bytesize (bz=1M) or similar to speed it up. I did this with a 1TB blockchain file successfully.

Mostly for Jim Abernathy's info, I pretty much stick to ext4, but was toying with idea of changing

James
Re: maria db [ In reply to ]
On Fri, Jun 2, 2023 at 8:33?AM James <jam@tigger.ws> wrote:

>
>
> On 2 Jun 2023, at 8:08 pm, Richard Shaw <hobbes1069@gmail.com> wrote:
>
> On Fri, Jun 2, 2023 at 6:54?AM James <jam@tigger.ws> wrote:
>
>> There is quite a lot of discussion on why not to use btrfs with maria
>> https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58
>>
>
> There's a few different solutions if you already have the files created
> since the +C must be done at creation.
>
> My method is to:
> mv <file> <file>_backup
> touch <file>
> chattr +C <file>
> dd if=<file>_backup of=<file>
>
> You can add bytesize (bz=1M) or similar to speed it up. I did this with a
> 1TB blockchain file successfully.
>
>
> Mostly for Jim Abernathy's info, I pretty much stick to ext4, but was
> toying with idea of changing
>
> James
>

I've used btrfs in a RAID 1 mirror array on my production backend with
mariadb for a year plus a few months without issues. I update about once a
month and that usually requires a reboot. The boot ssd also was installed
with btrfs with timeshift snapshots every hour.

I didn't do anything about COW disable at the time of install. I see from
the archlinux link that someone said it was addressed 2 years ago??? If
that's true, should I even need to worry about chattr +C <file>???

I learned most of what I know about BTRFS usage from the Kubuntu Forum.
They have a BTRFS category and I'll ask for knowledge over there.

I make special arrangements for COW issues for Virtual Machines by keeping
all qcow2 files on a separate ssd formatted ext4. I think that is required
because qcow2 files already use COW. I prefer this instead of chattr +C
/var/lib/libvirt/images. Using a separate ext4 ssd has the added benefit of
not having to recreate VMs when I change Distro every month or so because
some defect in my brain requires it.

Jim A
Re: maria db [ In reply to ]
> On 2 Jun 2023, at 8:59 pm, James Abernathy <jfabernathy@gmail.com> wrote:
>
>
>
> On Fri, Jun 2, 2023 at 8:33?AM James <jam@tigger.ws <mailto:jam@tigger.ws>> wrote:
>
>
>> On 2 Jun 2023, at 8:08 pm, Richard Shaw <hobbes1069@gmail.com <mailto:hobbes1069@gmail.com>> wrote:
>>
>> On Fri, Jun 2, 2023 at 6:54?AM James <jam@tigger.ws <mailto:jam@tigger.ws>> wrote:
>> There is quite a lot of discussion on why not to use btrfs with maria
>> https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58 <https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58>
>>
>> There's a few different solutions if you already have the files created since the +C must be done at creation.
>>
>> My method is to:
>> mv <file> <file>_backup
>> touch <file>
>> chattr +C <file> <>
>> dd if=<file>_backup of=<file>
>>
>> You can add bytesize (bz=1M) or similar to speed it up. I did this with a 1TB blockchain file successfully.
>
> Mostly for Jim Abernathy's info, I pretty much stick to ext4, but was toying with idea of changing
>
> James
>
> I've used btrfs in a RAID 1 mirror array on my production backend with mariadb for a year plus a few months without issues. I update about once a month and that usually requires a reboot. The boot ssd also was installed with btrfs with timeshift snapshots every hour.
>
> I didn't do anything about COW disable at the time of install. I see from the archlinux link that someone said it was addressed 2 years ago??? If that's true, should I even need to worry about chattr +C <file>??? <>
>
> I learned most of what I know about BTRFS usage from the Kubuntu Forum. They have a BTRFS category and I'll ask for knowledge over there.
>
> I make special arrangements for COW issues for Virtual Machines by keeping all qcow2 files on a separate ssd formatted ext4. I think that is required because qcow2 files already use COW. I prefer this instead of chattr +C /var/lib/libvirt/images. Using a separate ext4 ssd has the added benefit of not having to recreate VMs when I change Distro every month or so because some defect in my brain requires it.

Jim if you uncover anything interesting please post it (or even just mail me)
thanks
James
Re: maria db [ In reply to ]
On Fri, Jun 2, 2023 at 9:11?AM James <jam@tigger.ws> wrote:

>
>
> On 2 Jun 2023, at 8:59 pm, James Abernathy <jfabernathy@gmail.com> wrote:
>
>
>
> On Fri, Jun 2, 2023 at 8:33?AM James <jam@tigger.ws> wrote:
>
>>
>>
>> On 2 Jun 2023, at 8:08 pm, Richard Shaw <hobbes1069@gmail.com> wrote:
>>
>> On Fri, Jun 2, 2023 at 6:54?AM James <jam@tigger.ws> wrote:
>>
>>> There is quite a lot of discussion on why not to use btrfs with maria
>>> https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58
>>>
>>
>> There's a few different solutions if you already have the files created
>> since the +C must be done at creation.
>>
>> My method is to:
>> mv <file> <file>_backup
>> touch <file>
>> chattr +C <file>
>> dd if=<file>_backup of=<file>
>>
>> You can add bytesize (bz=1M) or similar to speed it up. I did this with a
>> 1TB blockchain file successfully.
>>
>>
>> Mostly for Jim Abernathy's info, I pretty much stick to ext4, but was
>> toying with idea of changing
>>
>> James
>>
>
> I've used btrfs in a RAID 1 mirror array on my production backend with
> mariadb for a year plus a few months without issues. I update about once a
> month and that usually requires a reboot. The boot ssd also was installed
> with btrfs with timeshift snapshots every hour.
>
> I didn't do anything about COW disable at the time of install. I see from
> the archlinux link that someone said it was addressed 2 years ago??? If
> that's true, should I even need to worry about chattr +C <file>???
>
> I learned most of what I know about BTRFS usage from the Kubuntu Forum.
> They have a BTRFS category and I'll ask for knowledge over there.
>
> I make special arrangements for COW issues for Virtual Machines by keeping
> all qcow2 files on a separate ssd formatted ext4. I think that is required
> because qcow2 files already use COW. I prefer this instead of chattr +C
> /var/lib/libvirt/images. Using a separate ext4 ssd has the added benefit of
> not having to recreate VMs when I change Distro every month or so because
> some defect in my brain requires it.
>
>
> Jim if you uncover anything interesting please post it (or even just mail
> me)
> thanks
> James
>

It must be fixed. I did lsattr /var/lib/mysql/ and the whole directory has
the COW disabled:

[root@eos-mythtv-master mythtv]# lsattr /var/lib/mysql/
---------------C------ /var/lib/mysql/aria_log_control
---------------C------ /var/lib/mysql/aria_log.00000001
---------------C------ /var/lib/mysql/ibdata1
---------------C------ /var/lib/mysql/ib_logfile0
---------------C------ /var/lib/mysql/mysql
---------------C------ /var/lib/mysql/performance_schema
---------------C------ /var/lib/mysql/sys
---------------C------ /var/lib/mysql/mysql_upgrade_info
---------------C------ /var/lib/mysql/multi-master.info
---------------C------ /var/lib/mysql/ddl_recovery-backup.log
---------------C------ /var/lib/mysql/mythconverg
---------------C------ /var/lib/mysql/ib_buffer_pool
---------------C------ /var/lib/mysql/ddl_recovery.log
---------------C------ /var/lib/mysql/ibtmp1
---------------C------ /var/lib/mysql/eos-mythtv-master.pid
Re: maria db [ In reply to ]
On Fri, Jun 2, 2023 at 9:19?AM James Abernathy <jfabernathy@gmail.com>
wrote:

>
>
> On Fri, Jun 2, 2023 at 9:11?AM James <jam@tigger.ws> wrote:
>
>>
>>
>> On 2 Jun 2023, at 8:59 pm, James Abernathy <jfabernathy@gmail.com> wrote:
>>
>>
>>
>> On Fri, Jun 2, 2023 at 8:33?AM James <jam@tigger.ws> wrote:
>>
>>>
>>>
>>> On 2 Jun 2023, at 8:08 pm, Richard Shaw <hobbes1069@gmail.com> wrote:
>>>
>>> On Fri, Jun 2, 2023 at 6:54?AM James <jam@tigger.ws> wrote:
>>>
>>>> There is quite a lot of discussion on why not to use btrfs with maria
>>>> https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58
>>>>
>>>
>>> There's a few different solutions if you already have the files created
>>> since the +C must be done at creation.
>>>
>>> My method is to:
>>> mv <file> <file>_backup
>>> touch <file>
>>> chattr +C <file>
>>> dd if=<file>_backup of=<file>
>>>
>>> You can add bytesize (bz=1M) or similar to speed it up. I did this with
>>> a 1TB blockchain file successfully.
>>>
>>>
>>> Mostly for Jim Abernathy's info, I pretty much stick to ext4, but was
>>> toying with idea of changing
>>>
>>> James
>>>
>>
>> I've used btrfs in a RAID 1 mirror array on my production backend with
>> mariadb for a year plus a few months without issues. I update about once a
>> month and that usually requires a reboot. The boot ssd also was installed
>> with btrfs with timeshift snapshots every hour.
>>
>> I didn't do anything about COW disable at the time of install. I see from
>> the archlinux link that someone said it was addressed 2 years ago??? If
>> that's true, should I even need to worry about chattr +C <file>???
>>
>> I learned most of what I know about BTRFS usage from the Kubuntu Forum.
>> They have a BTRFS category and I'll ask for knowledge over there.
>>
>> I make special arrangements for COW issues for Virtual Machines by
>> keeping all qcow2 files on a separate ssd formatted ext4. I think that is
>> required because qcow2 files already use COW. I prefer this instead of
>> chattr +C /var/lib/libvirt/images. Using a separate ext4 ssd has the added
>> benefit of not having to recreate VMs when I change Distro every month or
>> so because some defect in my brain requires it.
>>
>>
>> Jim if you uncover anything interesting please post it (or even just mail
>> me)
>> thanks
>> James
>>
>
> It must be fixed. I did lsattr /var/lib/mysql/ and the whole directory has
> the COW disabled:
>
> [root@eos-mythtv-master mythtv]# lsattr /var/lib/mysql/
> ---------------C------ /var/lib/mysql/aria_log_control
> ---------------C------ /var/lib/mysql/aria_log.00000001
> ---------------C------ /var/lib/mysql/ibdata1
> ---------------C------ /var/lib/mysql/ib_logfile0
> ---------------C------ /var/lib/mysql/mysql
> ---------------C------ /var/lib/mysql/performance_schema
> ---------------C------ /var/lib/mysql/sys
> ---------------C------ /var/lib/mysql/mysql_upgrade_info
> ---------------C------ /var/lib/mysql/multi-master.info
> ---------------C------ /var/lib/mysql/ddl_recovery-backup.log
> ---------------C------ /var/lib/mysql/mythconverg
> ---------------C------ /var/lib/mysql/ib_buffer_pool
> ---------------C------ /var/lib/mysql/ddl_recovery.log
> ---------------C------ /var/lib/mysql/ibtmp1
> ---------------C------ /var/lib/mysql/eos-mythtv-master.pid
>


FYI, this isn't the result I get with my production backend built over a
year ago on Ubuntu 22.04 The result posted above is from Ubuntu 23.04. So
I'm guessing I might need to do something on the production system to be
safe??

Jim A
Re: maria db [ In reply to ]
On Fri, Jun 2, 2023 at 9:37?AM James Abernathy <jfabernathy@gmail.com>
wrote:

>
>
> On Fri, Jun 2, 2023 at 9:19?AM James Abernathy <jfabernathy@gmail.com>
> wrote:
>
>>
>>
>> On Fri, Jun 2, 2023 at 9:11?AM James <jam@tigger.ws> wrote:
>>
>>>
>>>
>>> On 2 Jun 2023, at 8:59 pm, James Abernathy <jfabernathy@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> On Fri, Jun 2, 2023 at 8:33?AM James <jam@tigger.ws> wrote:
>>>
>>>>
>>>>
>>>> On 2 Jun 2023, at 8:08 pm, Richard Shaw <hobbes1069@gmail.com> wrote:
>>>>
>>>> On Fri, Jun 2, 2023 at 6:54?AM James <jam@tigger.ws> wrote:
>>>>
>>>>> There is quite a lot of discussion on why not to use btrfs with maria
>>>>> https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58
>>>>>
>>>>
>>>> There's a few different solutions if you already have the files created
>>>> since the +C must be done at creation.
>>>>
>>>> My method is to:
>>>> mv <file> <file>_backup
>>>> touch <file>
>>>> chattr +C <file>
>>>> dd if=<file>_backup of=<file>
>>>>
>>>> You can add bytesize (bz=1M) or similar to speed it up. I did this with
>>>> a 1TB blockchain file successfully.
>>>>
>>>>
>>>> Mostly for Jim Abernathy's info, I pretty much stick to ext4, but was
>>>> toying with idea of changing
>>>>
>>>> James
>>>>
>>>
>>> I've used btrfs in a RAID 1 mirror array on my production backend with
>>> mariadb for a year plus a few months without issues. I update about once a
>>> month and that usually requires a reboot. The boot ssd also was installed
>>> with btrfs with timeshift snapshots every hour.
>>>
>>> I didn't do anything about COW disable at the time of install. I see
>>> from the archlinux link that someone said it was addressed 2 years ago???
>>> If that's true, should I even need to worry about chattr +C <file>???
>>>
>>> I learned most of what I know about BTRFS usage from the Kubuntu Forum.
>>> They have a BTRFS category and I'll ask for knowledge over there.
>>>
>>> I make special arrangements for COW issues for Virtual Machines by
>>> keeping all qcow2 files on a separate ssd formatted ext4. I think that is
>>> required because qcow2 files already use COW. I prefer this instead of
>>> chattr +C /var/lib/libvirt/images. Using a separate ext4 ssd has the added
>>> benefit of not having to recreate VMs when I change Distro every month or
>>> so because some defect in my brain requires it.
>>>
>>>
>>> Jim if you uncover anything interesting please post it (or even just
>>> mail me)
>>> thanks
>>> James
>>>
>>
>> It must be fixed. I did lsattr /var/lib/mysql/ and the whole directory
>> has the COW disabled:
>>
>> [root@eos-mythtv-master mythtv]# lsattr /var/lib/mysql/
>> ---------------C------ /var/lib/mysql/aria_log_control
>> ---------------C------ /var/lib/mysql/aria_log.00000001
>> ---------------C------ /var/lib/mysql/ibdata1
>> ---------------C------ /var/lib/mysql/ib_logfile0
>> ---------------C------ /var/lib/mysql/mysql
>> ---------------C------ /var/lib/mysql/performance_schema
>> ---------------C------ /var/lib/mysql/sys
>> ---------------C------ /var/lib/mysql/mysql_upgrade_info
>> ---------------C------ /var/lib/mysql/multi-master.info
>> ---------------C------ /var/lib/mysql/ddl_recovery-backup.log
>> ---------------C------ /var/lib/mysql/mythconverg
>> ---------------C------ /var/lib/mysql/ib_buffer_pool
>> ---------------C------ /var/lib/mysql/ddl_recovery.log
>> ---------------C------ /var/lib/mysql/ibtmp1
>> ---------------C------ /var/lib/mysql/eos-mythtv-master.pid
>>
>
>
> FYI, this isn't the result I get with my production backend built over a
> year ago on Ubuntu 22.04 The result posted above is from Ubuntu 23.04. So
> I'm guessing I might need to do something on the production system to be
> safe??
>
> Jim A
>

The KubuntuForum guys think this is a performance issue with possible
impacts on HDD thrashing and wear and tear on SSDs; not data integrity. It
might not be an issue on low activity databases like mythconverg compared
to a database used only by a popular web server.

They reference this discussion:
https://superuser.com/questions/1124312/should-the-nodatacow-mount-option-be-used-in-btrfs-in-a-database-server-does-it

What I found out further is that the Kubutnu 22.04 LTS version of mariadb,
when installed on my production machine, didn't have chattr +C set for the
mysql directories and all the files do NOT have the COW disabled. Only my
test system with Endeavour OS (Archlinux) has that set to COW disabled.

My whole /var/lib/mysql directory is only 500MB with the only active
database (mythconverg) being less than 100MB. I think the database only
changes when data changes related to the metadata for TV recordings. So
very infrequent updating.

I think I'm going to leave the production system alone until it's time to
move to a new version of LTS and make sure COW disable is set in that
version of mariadb.

Jim A
Re: maria db [ In reply to ]
On 02/06/2023 15:36, James Abernathy wrote:
>
(snip)
>
> My whole /var/lib/mysql directory is only 500MB with the only active
> database (mythconverg) being less than 100MB. I think the database only
> changes when data changes related to the metadata for TV recordings. So
> very infrequent updating.
>
Heh. Did you forget the recordedseek table? That gets a lot of action every time you do a recording.

--

Mike Perkins


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: maria db [ In reply to ]
On Fri, Jun 2, 2023 at 11:43?AM Mike Perkins <mikep@randomtraveller.org.uk>
wrote:

> On 02/06/2023 15:36, James Abernathy wrote:
> >
> (snip)
> >
> > My whole /var/lib/mysql directory is only 500MB with the only active
> > database (mythconverg) being less than 100MB. I think the database only
> > changes when data changes related to the metadata for TV recordings. So
> > very infrequent updating.
> >
> Heh. Did you forget the recordedseek table? That gets a lot of action
> every time you do a recording.
>
> --
>
> Mike Perkins
>

I'm really not the judge of what is too much database writing. I record
no more than 3 hours a day some days. I just know that I've not had a
problem where the database didn't check out and optimize
successfully every day for 16 months. It may help that my btrfs boot drive
is 500GB where I only need < 50GB. The recordings and other mythtv
directories are on a separate disk array so they don't get used except for
writing recordings where COW would possibly be an issue. They are NAS HDDs
so not a problem.

The BTRFS snapshots saved my bacon a few weeks ago when I accidentally
clicked on upgrade database schema on a frontend thinking it was talking
about my test system when it was really for my production backend. One cmd
fixed that: sudo timeshift --restore, then select the hourly snapshot just
before my screwup.

JimA
Re: maria db [ In reply to ]
> On 2 Jun 2023, at 11:41 pm, Mike Perkins <mikep@randomtraveller.org.uk> wrote:
>
> (snip)
>> My whole /var/lib/mysql directory is only 500MB with the only active
>> database (mythconverg) being less than 100MB. I think the database only
>> changes when data changes related to the metadata for TV recordings. So
>> very infrequent updating.
> Heh. Did you forget the recordedseek table? That gets a lot of action every time you do a recording.

Mike would not (even recording) mythtv's use of the database be considered light compared to (I jest in fun) Amazon's USA inventry db ranked as heavy.
What I'm exploring is Jim's 1 year of use without problems quite to be expected.
James

If I recall from my youth at HP benchmarking SQL was multi-million transactions per second even updating seek table every frame on 10 recordings yields 500 trasactions per second!
Re: maria db [ In reply to ]
On Fri, Jun 2, 2023 at 9:11?AM James <jam@tigger.ws> wrote:

>
>
> On 2 Jun 2023, at 8:59 pm, James Abernathy <jfabernathy@gmail.com> wrote:
>
>
>
> On Fri, Jun 2, 2023 at 8:33?AM James <jam@tigger.ws> wrote:
>
>>
>>
>> On 2 Jun 2023, at 8:08 pm, Richard Shaw <hobbes1069@gmail.com> wrote:
>>
>> On Fri, Jun 2, 2023 at 6:54?AM James <jam@tigger.ws> wrote:
>>
>>> There is quite a lot of discussion on why not to use btrfs with maria
>>> https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58
>>>
>>
>> There's a few different solutions if you already have the files created
>> since the +C must be done at creation.
>>
>> My method is to:
>> mv <file> <file>_backup
>> touch <file>
>> chattr +C <file>
>> dd if=<file>_backup of=<file>
>>
>> You can add bytesize (bz=1M) or similar to speed it up. I did this with a
>> 1TB blockchain file successfully.
>>
>>
>> Mostly for Jim Abernathy's info, I pretty much stick to ext4, but was
>> toying with idea of changing
>>
>> James
>>
>
> I've used btrfs in a RAID 1 mirror array on my production backend with
> mariadb for a year plus a few months without issues. I update about once a
> month and that usually requires a reboot. The boot ssd also was installed
> with btrfs with timeshift snapshots every hour.
>
> I didn't do anything about COW disable at the time of install. I see from
> the archlinux link that someone said it was addressed 2 years ago??? If
> that's true, should I even need to worry about chattr +C <file>???
>
> I learned most of what I know about BTRFS usage from the Kubuntu Forum.
> They have a BTRFS category and I'll ask for knowledge over there.
>
> I make special arrangements for COW issues for Virtual Machines by keeping
> all qcow2 files on a separate ssd formatted ext4. I think that is required
> because qcow2 files already use COW. I prefer this instead of chattr +C
> /var/lib/libvirt/images. Using a separate ext4 ssd has the added benefit of
> not having to recreate VMs when I change Distro every month or so because
> some defect in my brain requires it.
>
>
> Jim if you uncover anything interesting please post it (or even just mail
> me)
> thanks
> James
>

I did discover that a normal install of mariadb-server on Kubuntu 23.04 on
a btrfs volume does NOT set the COW disable attr. I was able to mkdir -p
/var/lib/mysql first and the chattr +C /var/lib/mysql before the apt
install mariadb-server and that does setup all the right COW disable bits.

JIm A
Re: maria db [ In reply to ]
> On 3 Jun 2023, at 5:07 am, James Abernathy <jfabernathy@gmail.com> wrote:
>
>
>
> On Fri, Jun 2, 2023 at 9:11?AM James <jam@tigger.ws <mailto:jam@tigger.ws>> wrote:
>
>
>> On 2 Jun 2023, at 8:59 pm, James Abernathy <jfabernathy@gmail.com <mailto:jfabernathy@gmail.com>> wrote:
>>
>>
>>
>> On Fri, Jun 2, 2023 at 8:33?AM James <jam@tigger.ws <mailto:jam@tigger.ws>> wrote:
>>
>>
>>> On 2 Jun 2023, at 8:08 pm, Richard Shaw <hobbes1069@gmail.com <mailto:hobbes1069@gmail.com>> wrote:
>>>
>>> On Fri, Jun 2, 2023 at 6:54?AM James <jam@tigger.ws <mailto:jam@tigger.ws>> wrote:
>>> There is quite a lot of discussion on why not to use btrfs with maria
>>> https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58 <https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/58>
>>>
>>> There's a few different solutions if you already have the files created since the +C must be done at creation.
>>>
>>> My method is to:
>>> mv <file> <file>_backup
>>> touch <file>
>>> chattr +C <file> <>
>>> dd if=<file>_backup of=<file>
>>>
>>> You can add bytesize (bz=1M) or similar to speed it up. I did this with a 1TB blockchain file successfully.
>>
>> Mostly for Jim Abernathy's info, I pretty much stick to ext4, but was toying with idea of changing
>>
>> James
>>
>> I've used btrfs in a RAID 1 mirror array on my production backend with mariadb for a year plus a few months without issues. I update about once a month and that usually requires a reboot. The boot ssd also was installed with btrfs with timeshift snapshots every hour.
>>
>> I didn't do anything about COW disable at the time of install. I see from the archlinux link that someone said it was addressed 2 years ago??? If that's true, should I even need to worry about chattr +C <file>??? <>
>>
>> I learned most of what I know about BTRFS usage from the Kubuntu Forum. They have a BTRFS category and I'll ask for knowledge over there.
>>
>> I make special arrangements for COW issues for Virtual Machines by keeping all qcow2 files on a separate ssd formatted ext4. I think that is required because qcow2 files already use COW. I prefer this instead of chattr +C /var/lib/libvirt/images. Using a separate ext4 ssd has the added benefit of not having to recreate VMs when I change Distro every month or so because some defect in my brain requires it.
>
> Jim if you uncover anything interesting please post it (or even just mail me)
> thanks
> James
>
> I did discover that a normal install of mariadb-server on Kubuntu 23.04 on a btrfs volume does NOT set the COW disable attr. I was able to mkdir -p /var/lib/mysql first and the chattr +C /var/lib/mysql before the apt install mariadb-server and that does setup all the right COW disable bits.

Hmm 2 thread benchmark in the 350 transaction range; maybe mythtv is a heavy user
https://dba.stackexchange.com/questions/311348/mariadb-benchmarking-low-transaction-and-query-per-second <https://dba.stackexchange.com/questions/311348/mariadb-benchmarking-low-transaction-and-query-per-second>

James