Your message dated Tue, 25 Mar 2025 11:31:18 -0600
with message-id <[email protected]>
and subject line Re: btrfs-tools: subvolume is not recognized as parent if it
passed through another filesystem
has caused the Debian Bug report #743524,
regarding btrfs-tools: subvolume is not recognized as parent if it passed
through another filesystem
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
743524: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743524
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: btrfs-tools
Version: 3.12-1
Severity: normal
Dear Maintainer,
I'm not quite sure if this is expected behaviour or not. In a few words, for
send/receive operations, I can't use as parent a sub that was sent to
another filesystem and then re-sent to yet another filesystem.
The following script illustrates that. The expected behaviour in my opinion
would be to
end up with mnt/2 and mnt/3 being identical (both having subvRO1 and subvRO2).
#!/bin/bash
mkdir bugtest
cd bugtest
for i in 1 2 3; 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
btrfs sub create mnt/1/subv
date > mnt/1/subv/fileA
btrfs sub snap -r mnt/1/subv mnt/1/subvRO1
date > mnt/1/subv/fileB
btrfs sub snap -r mnt/1/subv mnt/1/subvRO2
# Sending the subvRO1 subvolume from 1 to 2 and then from 2 to 3
btrfs send mnt/1/subvRO1 | btrfs receive mnt/2
btrfs send mnt/2/subvRO1 | btrfs receive mnt/3
# works ok
btrfs send -p mnt/1/subvRO1 mnt/1/subvRO2 | btrfs receive mnt/2
# fails - why? mnt/3 received the parent subvRO1 indirectly via mnt/2
btrfs send -p mnt/1/subvRO1 mnt/1/subvRO2 | btrfs receive mnt/3
cd ..
umount bugtest/mnt/{1,2,3}
rm -rf bugtest/
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages btrfs-tools depends on:
ii e2fslibs 1.42.9-3
ii libblkid1 2.20.1-5.6
ii libc6 2.18-4
ii libcomerr2 1.42.9-3
ii liblzo2-2 2.06-1.2
ii libuuid1 2.20.1-5.6
ii zlib1g 1:1.2.8.dfsg-1
btrfs-tools recommends no packages.
btrfs-tools suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 6.2-1
Hello Giorgios,
Sorry it took so long for someone to reply to your bug. I salvaged
btrfs-progs in the last days of 2024 and am slowing catching up with the
backlog. Reply follows in-line:
Giorgos Pallas <[email protected]> wrote:
> Package: btrfs-tools
> Version: 3.12-1
> Severity: normal
>
> Dear Maintainer,
>
> I'm not quite sure if this is expected behaviour or not. In a few words, for
> send/receive operations, I can't use as parent a sub that was sent to
> another filesystem and then re-sent to yet another filesystem.
>
> The following script illustrates that. The expected behaviour in my opinion
> would be to
> end up with mnt/2 and mnt/3 being identical (both having subvRO1 and subvRO2).
<snip>
Thank you for the reproducer! This bug was fixed long, long ago. I'm
certain that this bug was present in btrfs 3.16, and I seem to remember
that it wasn't fixed until 4.4 or so.
At any rate, while I believe that this bug was fixed more than a few
years ago, the oldest system I have access to has btrfs-progs 6.2-1, so
I'm closing this bug as fixed with this version, because that's the
version I used to verify that this bug was fixed.
Sincerely,
Nicholas
signature.asc
Description: PGP signature
--- End Message ---
