summaryrefslogtreecommitdiff
path: root/arch/riscv
diff options
context:
space:
mode:
authorNikolay Borisov <nborisov@suse.com>2020-01-10 15:11:34 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-02-11 15:35:28 +0300
commitf3107a3c9b845db995d6bedee7a60d5309723a51 (patch)
treef74b5ec9df61b1029aeab0b8055cdb0df700d53a /arch/riscv
parentdd9837259de0734786db8b33d17865095789a0f7 (diff)
downloadlinux-f3107a3c9b845db995d6bedee7a60d5309723a51.tar.xz
btrfs: Handle another split brain scenario with metadata uuid feature
commit 05840710149c7d1a78ea85a2db5723f706e97d8f upstream. There is one more cases which isn't handled by the original metadata uuid work. Namely, when a filesystem has METADATA_UUID incompat bit and the user decides to change the FSID to the original one e.g. have metadata_uuid and fsid match. In case of power failure while this operation is in progress we could end up in a situation where some of the disks have the incompat bit removed and the other half have both METADATA_UUID_INCOMPAT and FSID_CHANGING_IN_PROGRESS flags. This patch handles the case where a disk that has successfully changed its FSID such that it equals METADATA_UUID is scanned first. Subsequently when a disk with both METADATA_UUID_INCOMPAT/FSID_CHANGING_IN_PROGRESS flags is scanned find_fsid_changed won't be able to find an appropriate btrfs_fs_devices. This is done by extending find_fsid_changed to correctly find btrfs_fs_devices whose metadata_uuid/fsid are the same and they match the metadata_uuid of the currently scanned device. Fixes: cc5de4e70256 ("btrfs: Handle final split-brain possibility during fsid change") Reviewed-by: Josef Bacik <josef@toxicpanda.com> Reported-by: Su Yue <Damenly_Su@gmx.com> Signed-off-by: Nikolay Borisov <nborisov@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch/riscv')
0 files changed, 0 insertions, 0 deletions