All of
 help / color / mirror / Atom feed
From: Roman Anasal | BDSU <>
To: "" <>
Cc: "" <>
Subject: Re: [PATCH v2 3/4] btrfs: send: fix invalid commands for inodes with changed rdev but same gen
Date: Sun, 31 Jan 2021 15:52:30 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jan 25, 2021 at 20:51 +0000 Filipe Manana wrote:
> On Mon, Jan 25, 2021 at 7:51 PM Roman Anasal <>
> wrote:
> > Second example:
> >   # case 2: same ino at different path
> >   btrfs subvolume create subvol1
> >   btrfs subvolume create subvol2
> >   mknod subvol1/a c 1 3
> >   mknod subvol2/b c 1 5
> >   btrfs property set subvol1 ro true
> >   btrfs property set subvol2 ro true
> >   btrfs send -p subvol1 subvol2 | btrfs receive --dump
> As I've told you before for the v1 patchset from a week or two ago,
> this is not a supported scenario for incremental sends.
> Incremental sends are meant to be used on RO snapshots of the same
> subvolume, and those snapshots must never be changed after they were
> created.
> Incremental sends were simply not designed for these cases, and can
> never be guaranteed to work with such cases.
> The bug is not having incremental sends fail right away, with an
> explicit error message, when the send and parent roots aren't RO
> snapshots of the same subvolume.

Since this should be fixed then I'd like to propose to add the
following check:

The inodes of the subvolumes' root directories (ino
BTRFS_FIRST_FREE_OBJECTID = 256) must have the same generation.

Since create_subvol() will always commit the transaction, i.e.
increment the generation, no two _independently_ created subvolumes can
be created within the same generation (are there race conditions
possible here?).
Taking a snapshot of a subvolume does not modify the generation of the
root dir inode. Also it is not possible to change or delete/re-create
the root directory of a subvolume since this would delete the subvolume

So having two subvolumes with root directories created with different
generations means they were created independently and can not share a
common ancestor. Doing an incremental send with them is unsafe and thus
must return an error.
With the root directories at the same generation though the subvolumes
are based on a common ancestor which is a requirement for a safe
incremental send.

Are my assumptions and my understanding here correct? Then this check
would catch most of the unsafe parents.
If so I could have a shot at a patch for this if you'd like me to?

This check still does not solve the second edge case though, when
snapshots are modified afterwards and diverge independently form one
another. For this I still see no good solution besides a new on-disk
flag whether a snapshot was *ever* set to ro=false. But with that I'm
not sure how to (not) inherit that flag in a safe way ...

  parent reply	other threads:[~2021-01-31 15:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25 19:42 [PATCH v2 0/4] btrfs: send: correctly recreate changed inodes Roman Anasal
2021-01-25 19:42 ` [PATCH v2 1/4] btrfs: send: rename send_ctx.cur_inode_new_gen to cur_inode_recreated Roman Anasal
2021-01-25 19:42 ` [PATCH v2 2/4] btrfs: send: fix invalid commands for inodes with changed type but same gen Roman Anasal
2021-01-25 19:42 ` [PATCH v2 3/4] btrfs: send: fix invalid commands for inodes with changed rdev " Roman Anasal
2021-01-25 20:51   ` Filipe Manana
2021-01-26 19:19     ` Roman Anasal | BDSU
2021-01-27 10:53       ` Filipe Manana
2021-01-31 15:52     ` Roman Anasal | BDSU [this message]
2021-02-02 11:56       ` Filipe Manana
2021-02-03 16:20         ` Roman Anasal | BDSU
2021-01-25 19:42 ` [PATCH v2 4/4] btrfs: send: fix invalid commands for inodes in disconnected roots Roman Anasal

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:

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

  git send-email \ \ \ \ \

* 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.