summaryrefslogtreecommitdiffstats
path: root/drivers/md/multipath.c
diff options
context:
space:
mode:
authorSong Liu <songliubraving@fb.com>2016-12-07 09:42:06 -0800
committerShaohua Li <shli@fb.com>2016-12-08 10:54:47 -0800
commit3c6edc66085e1d895a698c572bbfaf4d57fdb771 (patch)
tree97ee53cea93dd9e324eebd47c4f3a08b13ba9923 /drivers/md/multipath.c
parent5c88f403a5d2bd75911c6faaacc9bea97ac7d121 (diff)
downloadlinux-3c6edc66085e1d895a698c572bbfaf4d57fdb771.tar.bz2
md/r5cache: after recovery, increase journal seq by 10000
Currently, we increase journal entry seq by 10 after recovery. However, this is not sufficient in the following case. After crash the journal looks like | seq+0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | ... | +11 | +12 | If +1 is not valid, we dropped all entries from +1 to +12; and write seq+10: | seq+0 | +10 | +2 | +3 | +4 | +5 | +6 | +7 | ... | +11 | +12 | However, if we write a big journal entry with seq+11, it will connect with some stale journal entry: | seq+0 | +10 | +11 | +12 | To reduce the risk of this issue, we increase seq by 10000 instead. Shaohua: use 10000 instead of 1000. The risk should be very unlikely. The total stripe cache size is less than 2k typically, and several stripes can fit into one meta data block. So the total inflight meta data blocks would be quite small, which means the the total sequence number used should be quite small. The 10000 sequence number increase should be far more than safe. Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Shaohua Li <shli@fb.com>
Diffstat (limited to 'drivers/md/multipath.c')
0 files changed, 0 insertions, 0 deletions