Leszek Dubiel <[email protected]> writes: >> 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.
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. > 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! > Please close the bug. I would be happy to, but I just want to confirm there's nothing to fix/improve. > Since 2019 I have learned Btrfs better, > sorry for taking your time. 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
signature.asc
Description: PGP signature
