All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: "Dāvis Mosāns" <davispuh@gmail.com>
Cc: Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs send picks wrong subvolume UUID
Date: Sun, 2 Jan 2022 23:37:32 +0300	[thread overview]
Message-ID: <CAA91j0XmeOUA=sioDh7p8Of6O3n8=E8nCAeYs6GXE4awr=Cs+Q@mail.gmail.com> (raw)
In-Reply-To: <CAOE4rSz2f3xHj7Mi_JFgSMHHN8XSGxMr4NWZdcu4qd1-zOYOsg@mail.gmail.com>

On Sun, Jan 2, 2022 at 8:05 PM Dāvis Mosāns <davispuh@gmail.com> wrote:
>
> Hi,
>
> I have a bunch of snapshots I want to send from one fs to another,
> but it seems btrfs send is using received UUID instead of subvolumes own UUID
> causing wrong subvolume to be picked by btrfs receive and thus failing.
>
> $ btrfs subvolume show /mnt/fs/2019-11-02/etc | head -n 5
> 2019-11-02/etc
>         Name:                   etc
>         UUID:                   389ebc5e-341a-fb4a-b838-a2b7976b8220
>         Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
>         Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403
>

btrfs send will always use received UUID if available, it works as
designed and is not a bug. Bug is to have received UUID on read-write
subvolume. btrfs does not prevent it and it is the result of wrong
handling on the user side. You should never ever change read-only
subvolume used for send/receive to read-write directly - instead you
should always create writable clone from it.

This was discussed extensively, see e.g.
https://lore.kernel.org/linux-btrfs/d73a72b5-7b53-4ff3-f9b7-1a098868b967@gmail.com/

  reply	other threads:[~2022-01-02 20:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-02  4:17 btrfs send picks wrong subvolume UUID Dāvis Mosāns
2022-01-02 20:37 ` Andrei Borzenkov [this message]
2022-01-03 18:09   ` Dāvis Mosāns
2022-01-11 15:33     ` Nikolay Borisov
2022-01-11 16:46       ` Dāvis Mosāns
2022-01-12 11:29         ` David Sterba
2022-01-12 11:37     ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA91j0XmeOUA=sioDh7p8Of6O3n8=E8nCAeYs6GXE4awr=Cs+Q@mail.gmail.com' \
    --to=arvidjaar@gmail.com \
    --cc=davispuh@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.