- Package:
- btrfs-progs
- Source:
- btrfs-progs
- Description:
- Checksumming Copy on Write Filesystem utilities
- Submitter:
- Leszek Dubiel
- Date:
- 2025-04-28 20:57:01 UTC
- Severity:
- normal
- Tags:
Dear Maintainer,
1. created some subvolumes, transfered them successfully to another BTRFS file system with send/receive
2. created new subvolume, cp -a --reflink=always files, send to the same system and got error
Another system has set "default subvolume" to mount.
### HERE IS TESTING SCRIPT:
#!/bin/bash
mkdir bugtest
cd bugtest
for i in 1 2; do
mkdir -p mnt/$i
truncate -s 4G mnt/$i.img
mkfs.btrfs mnt/$i.img
mount -o loop mnt/$i.img mnt/$i
done
# make default subvol on 2, remount
btrfs sub create mnt/2/subDEF
btrfs sub set-default "$(btrfs sub list mnt/2 | egrep subDEF | cut -f 2 -d ' ')" mnt/2
umount mnt/2
mount -o loop mnt/2.img mnt/2
# create subvA in 1, send it to mnt/2
btrfs sub create mnt/1/subvA
dd if=/dev/urandom of=mnt/1/subvA/fileX bs=15M count=1
btrfs sub snap mnt/1/subvA -r mnt/1/subvA_ro
btrfs send mnt/1/subvA_ro | btrfs receive mnt/2/
# copy subvA to subvB, modify, send to mnt/2 (subvA as parent)
btrfs sub snap mnt/1/subvA mnt/1/subvB
mv mnt/1/subvB/fileX mnt/1/subvB/fileY
date >> mnt/1/subvB/fileY
btrfs sub snap mnt/1/subvB -r mnt/1/subvB_ro
btrfs send -p mnt/1/subvA_ro mnt/1/subvB_ro | btrfs receive mnt/2/
# relink files from subvA and subvB to new subvolume C, snap C as read only
btrfs sub create mnt/1/subvC
cp -a --reflink=always mnt/1/subvA_ro mnt/1/subvB_ro mnt/1/subvC
btrfs sub snap mnt/1/subvC -r mnt/1/subvC_ro
# now send subvC to mnt/2... but ERRORS:
# ERROR: cannot open subDEF/subvA_ro/fileX: No such file or directory
btrfs send -c mnt/1/subvA_ro -c mnt/1/subvB_ro mnt/1/subvC_ro | btrfs receive mnt/2/
# ERROR: cannot open subDEF/subvA_ro/fileX: No such file or directory
# btrfs send -p mnt/1/subvA_ro mnt/1/subvC_ro | btrfs receive mnt/2/
cd ..
umount bugtest/mnt/{1,2}
rm -rf bugtest/
# END OF TESTING SCRIPT
# OUTPUT OF TESTING BEGIN
btrfs-progs v4.20.1
Seehttp://btrfs.wiki.kernel.org for more information.
Label: (null)
UUID: 814d12e2-d639-4b96-93b2-a9cdb3af080a
Node size: 16384
Sector size: 4096
Filesystem size: 4.00GiB
Block group profiles:
Data: single 8.00MiB
Metadata: DUP 204.75MiB
System: DUP 8.00MiB
SSD detected: no
Incompat features: extref, skinny-metadata
Number of devices: 1
Devices:
ID SIZE PATH
1 4.00GiB mnt/1.img
btrfs-progs v4.20.1
Seehttp://btrfs.wiki.kernel.org for more information.
Label: (null)
UUID: 26d2fc51-8d81-4e04-9a17-a32339e5ac88
Node size: 16384
Sector size: 4096
Filesystem size: 4.00GiB
Block group profiles:
Data: single 8.00MiB
Metadata: DUP 204.75MiB
System: DUP 8.00MiB
SSD detected: no
Incompat features: extref, skinny-metadata
Number of devices: 1
Devices:
ID SIZE PATH
1 4.00GiB mnt/2.img
Create subvolume 'mnt/2/subDEF'
Create subvolume 'mnt/1/subvA'
1+0 przeczytanych rekordów
1+0 zapisanych rekordów
skopiowane 15728640 bajtów (16 MB, 15 MiB), 0,101825 s, 154 MB/s
Create a readonly snapshot of 'mnt/1/subvA' in 'mnt/1/subvA_ro'
At subvol mnt/1/subvA_ro
At subvol subvA_ro
Create a snapshot of 'mnt/1/subvA' in 'mnt/1/subvB'
Create a readonly snapshot of 'mnt/1/subvB' in 'mnt/1/subvB_ro'
At subvol mnt/1/subvB_ro
At snapshot subvB_ro
Create subvolume 'mnt/1/subvC'
Create a readonly snapshot of 'mnt/1/subvC' in 'mnt/1/subvC_ro'
At subvol mnt/1/subvC_ro
ERROR: parent determination failed for 263
ERROR: empty stream is not considered valid
# END OF OUTPUT
Someone has had the same problem:
https://www.spinics.net/lists/linux-btrfs/msg69286.html
https://www.spinics.net/lists/linux-btrfs/msg47650.html
Hi Leszek,
Leszek Dubiel <leszek@dubiel.pl> writes:
[snip]
What was this other system? I'm curious because, as far as I know, no
distribution officially supports the use of "set-default-subvolume".
Yes, reflink means that the data contained in subvC will be nonexclusive
to subvC; however, the *subvolume* subvC (and thus subvC_ro) has no
relationship to subvolumes A and B. You can verify this with
# btrfs sub list -uqt /filesystem/
Meanwhile, mnt/1/subvC/{subvA_ro,subvB_ro} are no longer subvolumes.
Why should this work, and what are you trying to do with this last
command? This looks like user error to me, because when clones are used
with a single parent, a btrfs stream is sent and recieved; Your command
appears to fail because no stream is sent. Use this instead (I've
tested it with snapshoting subvC from A or B, then proceeding with your
deduplicated subvol merging example, then running the send | receive
command).
# btrfs send -p mnt/1/subvA_ro -c mnt/1/subvB_ro mnt/1/subvC_ro | btrfs receive mnt/2/
Regards,
Nicholas
I have tested it again. Setting default subvolume is not relevant in this case. This is debian, but settting default is what I used to do in the past. ... ... You subvolumes A and B were not in a relationship with subvolume C, so this was "user error". Please close the bug. Since 2019 I have learned Btrfs better, sorry for taking your time.
Leszek Dubiel <leszek@dubiel.pl> writes: Yes, I know it's not relevant to "reflinked files and error parent determination failed". The reason I ask is because the topic of set-default-subvolume is being revisited in Debian. So to be clear, the "[an]other system" was also Debian? I'd also sincerely appreciate it if you would share your rationale for why you tried it, as well as why you stopped using it. To be fair, did you find that the documentation for "clones" was insufficient? It could be argued that an optimistic reading of the btrfs-progs docs would lead a user to suppose something like "oh neat! If I mark a bunch of subvolumes as clones then the kernel will figure everything out automatically, deduplicate, and only send the diff". If that's the case then it's an upstream documentation bug! I would be happy to, but I just want to confirm there's nothing to fix/improve. Truly, it's alright. Thank you for taking the time to file a bug. Also, sorry it took so long for someone to reply...I'm not sure why the previous maintainers didn't bother to write a couple words. Regards, Nicholas
Yes — it was Debian also. Long time ago I thought, that "set-default-subvolume" is a great feature. I can make many subvolumes, snapshots, and one special subvolume is marked as default, and when system is booted then this special subvolume becomes root. My current /etc/fstab looks like: UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 / btrfs noatime,degraded,compress=zstd,subvol=/orion UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 /mnt/root btrfs noatime,degraded,compress=zstd,subvol=/,noauto When I set /orion as default subvolume I can make fstab as simple as it used in old times for ext3: UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 / btrfs noatime,degraded,compress=zstd UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 /mnt/root btrfs noatime,degraded,compress=zstd,subvol=/,noauto But this is dangerous! For example when you run scripts from my first post in this thread, script changes default subvolume. It is unnnoticable — until you try to delete subvolumes. Btrfs complains "you can't delete default subvolume". If I would boot my server, then it will get stuck on boot process. So — the better solution is not to play with set-default-subvolume. Better if everything is explicit, always explicit: UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 / btrfs noatime,degraded,compress=zstd,subvol=/orion UUID=ea6ae51d-d9b0-4628-a8f3-3406e1dc59c6 /mnt/root btrfs noatime,degraded,compress=zstd,subvol=/,noauto #ls /mnt/root/ -1 orion orion_snaps # ls /mnt/root/orion bin boot czytaj dev etc home lib lib64 media mnt opt proc root run sbin snap spec srv sys tmp usr var # ls /mnt/root/orion_snaps -1 '2024-08-31 23:46:01 298933885' '2024-09-30 23:58:03 066051689' '2024-10-31 23:54:01 844345165' '2024-11-30 23:51:02 286451952' '2024-12-31 23:53:01 812712611' '2025-01-31 23:54:02 262220931' '2025-02-28 23:51:03 390687865' '2025-03-12 23:58:02 570605762' '2025-03-18 23:53:02 817283280' '2025-03-24 23:50:03 096441769' '2025-03-31 23:58:03 590689111' '2025-04-06 23:59:02 195100197' '2025-04-12 23:55:01 925146759' '2025-04-18 23:50:02 753467144' '2025-04-20 23:52:02 365647389' '2025-04-21 23:55:02 160780071' '2025-04-22 23:55:01 853546455' '2025-04-23 23:58:01 892381039' '2025-04-24 23:55:02 034121916' '2025-04-25 23:50:02 199518022' Another example — how to boot btrfs filesystem from grub command line? grub> root=(hd1,gpt2) grub> ls ($root)/ orion_snaps/ orion/ grub> probe --fs-uuid ($root) --set myid grub> echo $myid 0fac09ad-a5fd-4b43-b0bf-08d91655e3d8 grub> linux /orion/boot/vmlinuz-5.10.0-25-amd64 root=UUID=$myid rootflags=subvol=orion grub> initrd /orion/boot/initrd-img-5.10.0-25-amd64 grub> boot subvol=orion is important. Don't rely on 'set-default". :) :) So my advice for newbie in Btrfs would be: forget about default subvolume. I have search many, many times "what is the difference between -p and -c option". I have never found any good example how to use it. Maybe whole this bug is from my misunderstanding between -p and -c options. Why to use -c when you have -p? How could be "btrfs send -p -c -c ... | ssh .. btrfs receive" better then the same command without -c?