• Bug#934524: btrfs-progs: reflinked files and error parent determination

    From Nicholas D Steeves@21:1/5 to Leszek Dubiel on Tue Apr 22 18:00:01 2025
    Control: tag -1 moreinfo

    Hi Leszek,

    Leszek Dubiel <leszek@dubiel.pl> writes:

    Package: btrfs-progs
    Version: 4.20.1-2

    [snip]

    Another system has set "default subvolume" to mount.

    What was this other system? I'm curious because, as far as I know, no distribution officially supports the use of "set-default-subvolume".

    # 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

    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.

    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/

    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

    -----BEGIN PGP SIGNATURE-----

    iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgHuxkQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYVmaEACz7mEFS6rU240XZHUz1/F8ShEA474vV14l brAOdL+49hautLpvynm80MUmobj6ut7aw/I7bWyMIkSOvS57R+/Ux9WBlw3EHh6B Jas51G8LpPo1oj8PpIe+aiSRj6XZUUXCLAVPYMtagpHG5a0UNaV5ny2dRIsHW5Zb ulqU7Ykf/Uisq/X/Kb9fiN9sCggYHZTiZxUigNsEpU1nRfMc3wzOKeYPBZoOX0v2 x6N1U3CdrPr/Uc0jjdaYUwP2VPDwXb16J/zYH1HrZGNJQbwKE4jjMEQbcqH/KbSa n0sx7TogMOHJHwSCsPwbh82nzHOXtyYmdaFQmS2H+IJN88+ilh7+wQmyg3cVWTtR 59GJHH1OKwI5NHPlXPfnFIXy28AM5lfHivSqF8tH887+tkYk0q159DOopJM4Xmmb HpDLH/IUh20sGq0rW60kEO+/xyNFWmi+MkfLmTpIGAlzoWkYpl3a7D6taMREoQll Wxgfzc1nBvxHvushJZD+0pSf+qv4Bs/YxIVtdGXtBI4rwLOhhOSheVvq+ru7yhQt QN4nDQe2k8sURepOY/TbwxZn8J6nrk6AwgU74OGBA8JH/w8z9voVySxsH9+ZxhKn anjFl8wUXoA+SLDcXFfy/cNr9MtKwoLSjm+nhbkyCZSGLQnSihSmOvm/zTw6rBSF
    AU+WhZWR8g==
    =OUiP
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Leszek Dubiel@21:1/5 to All on Sun Apr 27 14:00:01 2025
    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, 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;
    ...


    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicholas D Steeves@21:1/5 to Leszek Dubiel on Mon Apr 28 21:00:01 2025
    Leszek Dubiel <leszek@dubiel.pl> 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

    -----BEGIN PGP SIGNATURE-----

    iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmgPzpUQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYWlUEAC31d9GwYPhvVU37O99wFgpmFcB8AJSmfd0 qHdIj5KYHWBZ6adUN11oxwbvgyir8h/gGFgmtV1DJ33nUo2aqGUU+Yq5+NxPYeXT LMOO5HiE17Ii+hUwszKLqAkCj3ICq29HkUIL3XfU0iocEyD0vr3TWzzD5N4B9Xq+ Pcp2dzs3UtffkrJJ2bAQmRoP5f0zwc3gx+EcFZvBiSAwYZ4Vsu7NfwVY0RVsdzC5 EJbABAgiRGSZrvQR163kcBPg55deDnvCL7FoE7OR31n/Fd7NKzdZVaNE+VST7IQ0 DYXtkEpPOlY6Ty+CZfy9yP89uZcqZymIjk/JlAoyGivKiYLET5CMhfqCo45OW/my genbCsYdx9L/WgWyd6YzH2LoVWMeXZXidQ2p3a1kM8BCkSjcXNsu5RT+zX8+1jzM qEWY/5Pex4lDNmHA+0GnLJPAZGzQMhCYrvJuXWCDXp18WI7g+Ob/CdTkoV/1hOh2 4clqucHPwyYPKwuwKPjDHaS/NZWkg/4Hpz3I64nxdPCm5kwpZixxJkThfOLEsrby a8ArKaJgAB0rKVURBqLhbLNj1C/Tl9TY/cRqnVnjLvumdWJCijQcJAUzQPyrZMFk gOPzNwax9EwTI1SYlqqCxJsyYr+zb3I3a8NQjNIWxVPbU+YT0X3D6oG2/aKRlM3E
    B/PVugucZw==
    =Q9gG
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Leszek Dubiel@21:1/5 to All on Mon Apr 28 23:00:01 2025
    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.


    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.








    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!

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)