Re: pg_upgrade cannot create btrfs clones on linux kernel 6.8.0 - Mailing list pgsql-bugs

From Michael Misiewicz
Subject Re: pg_upgrade cannot create btrfs clones on linux kernel 6.8.0
Date
Msg-id 18648bc4bdfda4532ec668b30c98d33ea1531a99@hey.com
Whole thread Raw
In response to Re: pg_upgrade cannot create btrfs clones on linux kernel 6.8.0  (Tomas Vondra <tomas@vondra.me>)
List pgsql-bugs
Tomas, 

Thanks for the great suggestion. That does seem like it'd be a likely cause of the issue, but not the case here (I was thinking if the bit was set, it might indicate an issue with the debian packages). 


$  sudo lsattr /var/lib/postgresql/16/main/PG_VERSION
---------------------- /var/lib/postgresql/16/main/PG_VERSION


Michael

On December 29, 2024, Tomas Vondra <tomas@vondra.me> wrote:
On 12/30/24 01:36, Michael Misiewicz wrote:
> ...
> I have validated that my filesystem supports reflinks:

> $ dd of=tempfile if=/dev/random bs=1M count=24
> 24+0 records in
> 24+0 records out
> 25165824 bytes (25 MB, 24 MiB) copied, 0.0806355 s, 312 MB/s
> $ cp --reflink=always tempfile tempfile.reflink
> $ btrfs filesystem du -s tempfile tempfile.reflink
> Total Exclusive Set shared Filename
> 24.00MiB 0.00B 24.00MiB tempfile
> 24.00MiB 0.00B 24.00MiB tempfile.reflink


> And there's nothing interesting in `dmesg`. 

> I ran this same command today on a macOS system (using apfs) and it
> worked great. I have no idea how to fix this problem and I'm curious if
> anyone has any pointers. 


What does lsattr say about the source files?

$ lsattr /var/lib/postgresql/16/main/PG_VERSION

Chances are there is "C" attribute set, i.e. NOCOW. In that case I get
exactly the same failure :

 could not clone file between old and new data directories: \
 Invalid argument


regards

-- 
Tomas Vondra

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18759: Missing files
Next
From: Tom Lane
Date:
Subject: Re: BUG #18758: Incorrect query result caused by ROLLUP operation