We need a mechanism to tell when to use the backup super_block.
To do this it needs a frame-work, and the patch #1 and #2 below
provides the same without change in the logic.
Its been found and posted to the list that check_mounted
needs access to the backup-sb and find-root as well. so
patch #3 provides frame work so that threads which need
the access to the backup sb can set the flag.
further,
patch#4 disables backup-sb access except for check_mounted
patch#5 provides backup-sb access to find-root
v5->v6:
Dropped patch
btrfs-progs: make btrfs dev scan multi path aware
sorry its a wrong patch, further this branch does not find
the problem this patch was trying to address
Added patch#5
-----------------
v4->v5:
Rebase with integration-20130321 and with my own changes (patch #1)
Allow check_mounted thread-path to use backup-sb
v3->v4:
Fixed some warnings introduced by patch #3 below,
sorry my mistake.
v2->v3:
Accepts David and Eric review, which would result in disabled
access to backup-superblock by default.
Dropped the patch
[PATCH 3/3] btrfs-progs: use BTRFS_SCAN_BACKUP_SB flag in btrfs_scan_one_device
Introduced a new patch
[PATCH 3/3] btrfs-progs: disable using backup superblock by default
v1->v2:
Accepts Eric and Zach review.
Separates fix into 3 patches for easy logical understanding
Anand Jain (5):
btrfs-progs: Introduce flag BTRFS_SCAN_REGISTER to replace run_ioctl
btrfs-progs: Introduce flag BTRFS_SCAN_BACKUP_SB for
btrfs_read_dev_super
btrfs-progs: introduce passing flags to btrfs_scan_one_device
btrfs-progs: disable using backup superblock by default
btrfs-progs: btrfs-find-root should scan backup-sb
cmds-device.c | 4 ++--
cmds-replace.c | 2 +-
disk-io.c | 15 ++++++++++-----
disk-io.h | 3 ++-
find-root.c | 9 ++++++---
utils.c | 29 +++++++++++++++++------------
utils.h | 8 +++++---
volumes.c | 6 ++++--
volumes.h | 2 +-
9 files changed, 48 insertions(+), 30 deletions(-)
--
1.8.1.227.g44fe835
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
