Package: btrfs-progs
Version: 4.20.1-2
Another system has set "default subvolume" to mount.
# 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/
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.
This looks like user error to me, because when clones are used...
with a single parent, a btrfs stream is sent and recieved;
What was this other system? I'm curious because, as far as I know, no
distribution officially supports the use of "set-default-subvolume".
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.
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.
You subvolumes A and B were not in a relationship with subvolume C,
so this was "user error".
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!
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 481 |
Nodes: | 16 (3 / 13) |
Uptime: | 17:55:11 |
Calls: | 9,542 |
Calls today: | 2 |
Files: | 13,653 |
Messages: | 6,139,890 |