OSDN Git Service

btrfs: Streamline btrfs_fs_info::backup_root_index semantics
authorNikolay Borisov <nborisov@suse.com>
Tue, 15 Oct 2019 15:42:24 +0000 (18:42 +0300)
committerDavid Sterba <dsterba@suse.com>
Mon, 18 Nov 2019 16:51:47 +0000 (17:51 +0100)
commit6ef108dd0cda65d3031166222e64cdf71fdd3359
tree38b0a01cc94b0e1c1ec3471b3ad5e63f38f530ff
parent4ac039ad75df3f5f5f5b2b7439f094ad5bd9dbbe
btrfs: Streamline btrfs_fs_info::backup_root_index semantics

The backup_root_index member stores the index at which the backup root
should be saved upon next transaction commit. However, there is a
small deviation from this behavior in the form of a check in
backup_super_roots which checks if current root generation equals to the
generation of the previous root. This can trigger in the following
scenario:

slot0: gen-2
slot1: gen-1
slot2: gen
slot3: unused

Now suppose slot3 (which is also the root specified in the super block)
is corrupted hence init_tree_roots chooses to use the backup root at
slot2, meaning read_backup_root will read slot2 and assign the
superblock generation to gen-1. Despite this backup_root_index will
point at slot3 because its init happens in init_backup_root_slot, long
before any parsing of the backup roots occur. Then on next transaction
start, gen-1 will be incremented by 1 making the root's generation
equal gen. Subsequently, on transaction commit the following check
triggers:

  if (btrfs_backup_tree_root_gen(root_backup) ==
           btrfs_header_generation(info->tree_root->node))

This causes the 'next_backup', which is the index at which the backup is
going to be written to, to set to last_backup, which will be slot2.

All of this is a very confusing way of expressing the following
invariant:

 Always write a backup root at the index following the last used backup
 root.

This commit streamlines this logic by setting backup_root_index to the
next index after the one used for mount.

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/disk-io.c