2022-11-22 14:43:01 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2011-12-03 11:18:56 +01:00
|
|
|
|
2016-06-14 00:26:31 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-01-26 18:45:11 +01:00
|
|
|
|
|
|
|
|
|
2018-05-20 18:25:48 -04:00
|
|
|
|
2011-01-26 18:45:11 +01:00
|
|
|
|
|
|
|
|
|
2015-03-24 16:22:32 -07:00
|
|
|
|
2011-01-26 18:45:11 +01:00
|
|
|
|
2016-06-14 00:26:31 +02:00
|
|
|
|
drbd: introduce P_ZEROES (REQ_OP_WRITE_ZEROES on the "wire")
And also re-enable partial-zero-out + discard aligned.
With the introduction of REQ_OP_WRITE_ZEROES,
we started to use that for both WRITE_ZEROES and DISCARDS,
hoping that WRITE_ZEROES would "do what we want",
UNMAP if possible, zero-out the rest.
The example scenario is some LVM "thin" backend.
While an un-allocated block on dm-thin reads as zeroes, on a dm-thin
with "skip_block_zeroing=true", after a partial block write allocated
that block, that same block may well map "undefined old garbage" from
the backends on LBAs that have not yet been written to.
If we cannot distinguish between zero-out and discard on the receiving
side, to avoid "undefined old garbage" to pop up randomly at later times
on supposedly zero-initialized blocks, we'd need to map all discards to
zero-out on the receiving side. But that would potentially do a full
alloc on thinly provisioned backends, even when the expectation was to
unmap/trim/discard/de-allocate.
We need to distinguish on the protocol level, whether we need to guarantee
zeroes (and thus use zero-out, potentially doing the mentioned full-alloc),
or if we want to put the emphasis on discard, and only do a "best effort
zeroing" (by "discarding" blocks aligned to discard-granularity, and zeroing
only potential unaligned head and tail clippings to at least *try* to
avoid "false positives" in an online-verify later), hoping that someone
set skip_block_zeroing=false.
For some discussion regarding this on dm-devel, see also
https://www.mail-archive.com/dm-devel%40redhat.com/msg07965.html
https://www.redhat.com/archives/dm-devel/2018-January/msg00271.html
For backward compatibility, P_TRIM means zero-out, unless the
DRBD_FF_WZEROES feature flag is agreed upon during handshake.
To have upper layers even try to submit WRITE ZEROES requests,
we need to announce "efficient zeroout" independently.
We need to fixup max_write_zeroes_sectors after blk_queue_stack_limits():
if we can handle "zeroes" efficiently on the protocol,
we want to do that, even if our backend does not announce
max_write_zeroes_sectors itself.
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-12-20 17:23:42 +01:00
|
|
|
|
2016-06-14 00:26:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-28 10:31:04 +01:00
|
|
|
|
2011-01-26 18:45:11 +01:00
|
|
|
|
2013-10-11 15:44:27 -07:00
|
|
|
|
|
|
|
|
|
2011-01-27 14:42:51 +01:00
|
|
|
|
2011-01-28 10:31:04 +01:00
|
|
|
|
|
|
|
|
|
2011-01-26 18:45:11 +01:00
|
|
|
|
|
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
|
|
|
|
|
2011-01-26 18:45:11 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2012-01-24 16:58:11 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2012-01-24 16:58:11 +01:00
|
|
|
|
2011-01-26 18:45:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-20 11:19:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-24 10:12:36 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 16:58:11 +01:00
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-27 15:07:43 +02:00
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drbd: fix potential deadlock during "restart" of conflicting writes
w_restart_write(), run from worker context, calls __drbd_make_request()
and further drbd_al_begin_io(, delegate=true), which then
potentially deadlocks. The previous patch moved a BUG_ON to expose
such call paths, which would now be triggered.
Also, if we call __drbd_make_request() from resource worker context,
like w_restart_write() did, and that should block for whatever reason
(!drbd_state_is_stable(), resource suspended, ...),
we potentially deadlock the whole resource, as the worker
is needed for state changes and other things.
Create a dedicated retry workqueue for this instead.
Also make sure that inc_ap_bio()/dec_ap_bio() are properly paired,
even if do_retry() needs to retry itself,
in case __drbd_make_request() returns != 0.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
2011-11-24 10:36:25 +01:00
|
|
|
|
2010-05-27 15:07:43 +02:00
|
|
|
|
2014-03-20 11:19:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-24 16:58:11 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-09-03 14:08:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-30 12:27:44 +02:00
|
|
|
|
2012-09-03 14:08:35 +02:00
|
|
|
|
2012-08-28 14:39:44 +02:00
|
|
|
|
2023-03-30 12:27:44 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-08-28 14:39:44 +02:00
|
|
|
|
2023-03-30 12:27:44 +02:00
|
|
|
|
2012-08-28 14:39:44 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-02-17 16:46:59 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-29 15:23:14 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-01 12:03:49 +01:00
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2011-03-31 15:18:56 +02:00
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-05-20 18:25:48 -04:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-05-30 16:32:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-11-28 15:04:49 +01:00
|
|
|
|
2011-05-30 16:32:41 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-08-07 06:42:09 +02:00
|
|
|
|
2011-05-30 16:32:41 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-05-30 16:32:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
drbd: fix potential silent data corruption
Scenario:
---------
bio chain generated by blk_queue_split().
Some split bio fails and propagates its error status to the "parent" bio.
But then the (last part of the) parent bio itself completes without error.
We would clobber the already recorded error status with BLK_STS_OK,
causing silent data corruption.
Reproducer:
-----------
How to trigger this in the real world within seconds:
DRBD on top of degraded parity raid,
small stripe_cache_size, large read_ahead setting.
Drop page cache (sysctl vm.drop_caches=1, fadvise "DONTNEED",
umount and mount again, "reboot").
Cause significant read ahead.
Large read ahead request is split by blk_queue_split().
Parts of the read ahead that are already in the stripe cache,
or find an available stripe cache to use, can be serviced.
Parts of the read ahead that would need "too much work",
would need to wait for a "stripe_head" to become available,
are rejected immediately.
For larger read ahead requests that are split in many pieces, it is very
likely that some "splits" will be serviced, but then the stripe cache is
exhausted/busy, and the remaining ones will be rejected.
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com>
Cc: <stable@vger.kernel.org> # 4.13.x
Link: https://lore.kernel.org/r/20220330185551.3553196-1-christoph.boehmwalder@linbit.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-03-30 20:55:51 +02:00
|
|
|
|
|
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-28 10:31:04 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-26 17:02:45 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2011-05-31 14:33:49 +02:00
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2020-05-27 07:24:05 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
|
|
|
|
|
2016-08-05 15:35:16 -06:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-20 11:19:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2014-03-20 11:19:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
2017-05-11 10:21:46 +02:00
|
|
|
|
2010-06-23 17:18:51 +02:00
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2010-06-23 17:18:51 +02:00
|
|
|
|
2017-05-11 10:21:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2017-05-11 10:21:46 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2017-05-11 10:21:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-24 10:12:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-11 10:21:46 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2017-05-11 10:21:46 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 00:03:49 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 00:03:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2022-04-01 00:03:49 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 00:03:49 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 00:03:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2022-04-01 00:03:49 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 00:03:49 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-01 00:03:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2022-04-01 00:03:49 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-08-14 11:28:52 +02:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-14 17:34:19 +01:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2015-03-16 16:08:29 +01:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
2015-05-18 14:08:46 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2012-08-14 11:28:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-14 17:34:19 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2016-11-14 17:34:19 +01:00
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2017-05-11 10:21:46 +02:00
|
|
|
|
|
|
|
|
|
2010-06-23 17:18:51 +02:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-09-26 14:07:04 +02:00
|
|
|
|
2022-12-01 12:03:49 +01:00
|
|
|
|
2012-09-26 14:07:04 +02:00
|
|
|
|
|
|
|
|
|
2022-07-13 07:53:11 +02:00
|
|
|
|
2012-09-26 14:07:04 +02:00
|
|
|
|
2012-09-27 15:19:38 +02:00
|
|
|
|
|
|
|
|
|
2022-07-13 07:53:11 +02:00
|
|
|
|
2012-09-26 14:07:04 +02:00
|
|
|
|
|
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-30 12:27:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2010-06-09 14:07:43 +02:00
|
|
|
|
2023-03-30 12:27:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
|
|
|
|
|
2011-04-19 17:10:19 +02:00
|
|
|
|
2011-04-13 16:24:47 -07:00
|
|
|
|
2011-02-22 02:15:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2011-02-22 02:15:32 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2011-04-19 17:10:19 +02:00
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
2011-04-19 17:10:19 +02:00
|
|
|
|
|
|
|
|
|
2011-04-13 16:24:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2011-02-22 02:15:32 +01:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2011-03-14 13:01:50 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-07-05 15:38:59 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2011-03-14 13:01:50 +01:00
|
|
|
|
|
|
|
|
|
drbd: always write bitmap on detach
If we detach due to local read-error (which sets a bit in the bitmap),
stay Primary, and then re-attach (which re-reads the bitmap from disk),
we potentially lost the "out-of-sync" (or, "bad block") information in
the bitmap.
Always (try to) write out the changed bitmap pages before going diskless.
That way, we don't lose the bit for the bad block,
the next resync will fetch it from the peer, and rewrite
it locally, which may result in block reallocation in some
lower layer (or the hardware), and thereby "heal" the bad blocks.
If the bitmap writeout errors out as well, we will (again: try to)
mark the "we need a full sync" bit in our super block,
if it was a READ error; writes are covered by the activity log already.
If that superblock does not make it to disk either, we are sorry.
Maybe we just lost an entire disk or controller (or iSCSI connection),
and there actually are no bad blocks at all, so we don't need to
re-fetch from the peer, there is no "auto-healing" necessary.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
2012-09-27 15:18:21 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
|
|
|
|
|
drbd: always write bitmap on detach
If we detach due to local read-error (which sets a bit in the bitmap),
stay Primary, and then re-attach (which re-reads the bitmap from disk),
we potentially lost the "out-of-sync" (or, "bad block") information in
the bitmap.
Always (try to) write out the changed bitmap pages before going diskless.
That way, we don't lose the bit for the bad block,
the next resync will fetch it from the peer, and rewrite
it locally, which may result in block reallocation in some
lower layer (or the hardware), and thereby "heal" the bad blocks.
If the bitmap writeout errors out as well, we will (again: try to)
mark the "we need a full sync" bit in our super block,
if it was a READ error; writes are covered by the activity log already.
If that superblock does not make it to disk either, we are sorry.
Maybe we just lost an entire disk or controller (or iSCSI connection),
and there actually are no bad blocks at all, so we don't need to
re-fetch from the peer, there is no "auto-healing" necessary.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
2012-09-27 15:18:21 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2026-02-20 12:39:37 +01:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2014-04-28 18:43:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-10-03 13:56:25 -07:00
|
|
|
|
2014-04-28 18:43:24 +02:00
|
|
|
|
2012-03-26 17:29:30 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-22 02:15:32 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2012-03-26 17:02:45 +02:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2012-03-26 17:29:30 +02:00
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-02-22 02:15:32 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-03-26 17:02:45 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-22 02:15:32 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-03 02:22:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-04-19 17:10:19 +02:00
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
2011-04-19 17:10:19 +02:00
|
|
|
|
|
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2010-12-19 23:53:14 +01:00
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2010-10-27 14:33:00 +02:00
|
|
|
|
|
|
|
|
|
2012-03-26 16:46:39 +02:00
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-11 09:43:25 +01:00
|
|
|
|
|
|
|
|
|
2012-03-26 16:44:59 +02:00
|
|
|
|
2012-01-11 09:43:25 +01:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2012-08-01 12:33:51 +02:00
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-07-24 09:31:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-01 12:33:51 +02:00
|
|
|
|
2012-07-24 09:31:18 +02:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
|
|
|
|
|
2012-07-24 09:31:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-26 16:51:11 +02:00
|
|
|
|
2012-07-24 09:31:18 +02:00
|
|
|
|
2021-04-20 15:25:51 -05:00
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2014-03-20 11:19:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-23 14:42:19 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-03-23 14:42:19 +01:00
|
|
|
|
2011-04-13 16:24:47 -07:00
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-04-13 16:24:47 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-02-22 02:15:32 +01:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2011-04-13 16:24:47 -07:00
|
|
|
|
2011-02-22 02:15:32 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2011-02-22 02:15:32 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2012-08-07 06:47:14 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2010-05-31 10:14:17 +02:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2010-05-31 10:14:17 +02:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2010-05-31 10:14:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-31 10:14:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2010-05-31 10:14:17 +02:00
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2010-05-31 10:14:17 +02:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2012-07-31 11:22:58 +02:00
|
|
|
|
|
|
|
|
|
2012-08-07 13:28:00 +02:00
|
|
|
|
2012-07-31 11:22:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-12 17:08:26 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
2012-03-26 17:02:45 +02:00
|
|
|
|
|
|
|
|
|
2010-05-12 17:08:26 +02:00
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-12 17:08:26 +02:00
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
|
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2010-05-12 17:08:26 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2010-05-12 17:08:26 +02:00
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2010-05-12 17:08:26 +02:00
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2010-05-27 15:07:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-08-17 12:43:25 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-01-25 15:37:43 +01:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2013-03-27 14:08:41 +01:00
|
|
|
|
|
|
|
|
|
2013-11-22 12:40:58 +01:00
|
|
|
|
2013-03-27 14:08:41 +01:00
|
|
|
|
|
|
|
|
|
2019-11-28 11:09:30 +08:00
|
|
|
|
2010-06-09 14:07:43 +02:00
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2010-12-19 20:48:29 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2010-12-19 20:48:29 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2020-09-25 18:06:17 +02:00
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2011-11-11 12:31:20 +01:00
|
|
|
|
2011-11-17 10:12:31 +01:00
|
|
|
|
2011-11-11 12:31:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-06 21:07:15 +02:00
|
|
|
|
2011-11-11 12:31:20 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
|
|
|
|
|
2011-11-17 10:12:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-11 12:31:20 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2011-11-11 12:31:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-28 15:53:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
|
|
|
|
|
2011-01-28 15:53:51 +01:00
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
2011-01-28 15:53:51 +01:00
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-01-28 15:53:51 +01:00
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
2016-06-14 00:26:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
2016-06-14 00:26:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
2016-06-14 00:26:17 +02:00
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
2011-07-07 14:19:42 +02:00
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
2011-07-07 14:19:42 +02:00
|
|
|
|
2011-01-28 15:53:51 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2011-01-28 15:53:51 +01:00
|
|
|
|
|
|
|
|
|
2016-06-14 00:26:35 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
2011-05-31 14:33:49 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-27 14:08:45 +01:00
|
|
|
|
2011-05-30 16:32:41 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2013-03-27 14:08:45 +01:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2011-05-30 16:32:41 +02:00
|
|
|
|
2012-07-30 09:06:26 +02:00
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
2014-03-20 14:04:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-07 06:42:09 +02:00
|
|
|
|
2011-05-31 14:33:49 +02:00
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-06-08 14:17:36 +02:00
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-08 17:48:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2023-03-30 12:27:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2012-08-03 02:19:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-05 15:35:16 -06:00
|
|
|
|
2012-08-07 06:42:09 +02:00
|
|
|
|
2023-03-30 12:27:43 +02:00
|
|
|
|
2013-03-27 14:08:41 +01:00
|
|
|
|
2012-08-03 02:19:09 +02:00
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
2023-03-30 12:27:43 +02:00
|
|
|
|
|
|
|
|
|
2023-03-30 12:27:44 +02:00
|
|
|
|
2023-03-30 12:27:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drbd: introduce P_ZEROES (REQ_OP_WRITE_ZEROES on the "wire")
And also re-enable partial-zero-out + discard aligned.
With the introduction of REQ_OP_WRITE_ZEROES,
we started to use that for both WRITE_ZEROES and DISCARDS,
hoping that WRITE_ZEROES would "do what we want",
UNMAP if possible, zero-out the rest.
The example scenario is some LVM "thin" backend.
While an un-allocated block on dm-thin reads as zeroes, on a dm-thin
with "skip_block_zeroing=true", after a partial block write allocated
that block, that same block may well map "undefined old garbage" from
the backends on LBAs that have not yet been written to.
If we cannot distinguish between zero-out and discard on the receiving
side, to avoid "undefined old garbage" to pop up randomly at later times
on supposedly zero-initialized blocks, we'd need to map all discards to
zero-out on the receiving side. But that would potentially do a full
alloc on thinly provisioned backends, even when the expectation was to
unmap/trim/discard/de-allocate.
We need to distinguish on the protocol level, whether we need to guarantee
zeroes (and thus use zero-out, potentially doing the mentioned full-alloc),
or if we want to put the emphasis on discard, and only do a "best effort
zeroing" (by "discarding" blocks aligned to discard-granularity, and zeroing
only potential unaligned head and tail clippings to at least *try* to
avoid "false positives" in an online-verify later), hoping that someone
set skip_block_zeroing=false.
For some discussion regarding this on dm-devel, see also
https://www.mail-archive.com/dm-devel%40redhat.com/msg07965.html
https://www.redhat.com/archives/dm-devel/2018-January/msg00271.html
For backward compatibility, P_TRIM means zero-out, unless the
DRBD_FF_WZEROES feature flag is agreed upon during handshake.
To have upper layers even try to submit WRITE ZEROES requests,
we need to announce "efficient zeroout" independently.
We need to fixup max_write_zeroes_sectors after blk_queue_stack_limits():
if we can handle "zeroes" efficiently on the protocol,
we want to do that, even if our backend does not announce
max_write_zeroes_sectors itself.
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-12-20 17:23:42 +01:00
|
|
|
|
2016-06-14 00:26:22 +02:00
|
|
|
|
drbd: introduce P_ZEROES (REQ_OP_WRITE_ZEROES on the "wire")
And also re-enable partial-zero-out + discard aligned.
With the introduction of REQ_OP_WRITE_ZEROES,
we started to use that for both WRITE_ZEROES and DISCARDS,
hoping that WRITE_ZEROES would "do what we want",
UNMAP if possible, zero-out the rest.
The example scenario is some LVM "thin" backend.
While an un-allocated block on dm-thin reads as zeroes, on a dm-thin
with "skip_block_zeroing=true", after a partial block write allocated
that block, that same block may well map "undefined old garbage" from
the backends on LBAs that have not yet been written to.
If we cannot distinguish between zero-out and discard on the receiving
side, to avoid "undefined old garbage" to pop up randomly at later times
on supposedly zero-initialized blocks, we'd need to map all discards to
zero-out on the receiving side. But that would potentially do a full
alloc on thinly provisioned backends, even when the expectation was to
unmap/trim/discard/de-allocate.
We need to distinguish on the protocol level, whether we need to guarantee
zeroes (and thus use zero-out, potentially doing the mentioned full-alloc),
or if we want to put the emphasis on discard, and only do a "best effort
zeroing" (by "discarding" blocks aligned to discard-granularity, and zeroing
only potential unaligned head and tail clippings to at least *try* to
avoid "false positives" in an online-verify later), hoping that someone
set skip_block_zeroing=false.
For some discussion regarding this on dm-devel, see also
https://www.mail-archive.com/dm-devel%40redhat.com/msg07965.html
https://www.redhat.com/archives/dm-devel/2018-January/msg00271.html
For backward compatibility, P_TRIM means zero-out, unless the
DRBD_FF_WZEROES feature flag is agreed upon during handshake.
To have upper layers even try to submit WRITE ZEROES requests,
we need to announce "efficient zeroout" independently.
We need to fixup max_write_zeroes_sectors after blk_queue_stack_limits():
if we can handle "zeroes" efficiently on the protocol,
we want to do that, even if our backend does not announce
max_write_zeroes_sectors itself.
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-12-20 17:23:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-03 09:38:06 +02:00
|
|
|
|
2016-06-14 00:26:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-28 15:27:51 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-08-05 15:35:16 -06:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
drbd: introduce P_ZEROES (REQ_OP_WRITE_ZEROES on the "wire")
And also re-enable partial-zero-out + discard aligned.
With the introduction of REQ_OP_WRITE_ZEROES,
we started to use that for both WRITE_ZEROES and DISCARDS,
hoping that WRITE_ZEROES would "do what we want",
UNMAP if possible, zero-out the rest.
The example scenario is some LVM "thin" backend.
While an un-allocated block on dm-thin reads as zeroes, on a dm-thin
with "skip_block_zeroing=true", after a partial block write allocated
that block, that same block may well map "undefined old garbage" from
the backends on LBAs that have not yet been written to.
If we cannot distinguish between zero-out and discard on the receiving
side, to avoid "undefined old garbage" to pop up randomly at later times
on supposedly zero-initialized blocks, we'd need to map all discards to
zero-out on the receiving side. But that would potentially do a full
alloc on thinly provisioned backends, even when the expectation was to
unmap/trim/discard/de-allocate.
We need to distinguish on the protocol level, whether we need to guarantee
zeroes (and thus use zero-out, potentially doing the mentioned full-alloc),
or if we want to put the emphasis on discard, and only do a "best effort
zeroing" (by "discarding" blocks aligned to discard-granularity, and zeroing
only potential unaligned head and tail clippings to at least *try* to
avoid "false positives" in an online-verify later), hoping that someone
set skip_block_zeroing=false.
For some discussion regarding this on dm-devel, see also
https://www.mail-archive.com/dm-devel%40redhat.com/msg07965.html
https://www.redhat.com/archives/dm-devel/2018-January/msg00271.html
For backward compatibility, P_TRIM means zero-out, unless the
DRBD_FF_WZEROES feature flag is agreed upon during handshake.
To have upper layers even try to submit WRITE ZEROES requests,
we need to announce "efficient zeroout" independently.
We need to fixup max_write_zeroes_sectors after blk_queue_stack_limits():
if we can handle "zeroes" efficiently on the protocol,
we want to do that, even if our backend does not announce
max_write_zeroes_sectors itself.
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2018-12-20 17:23:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2020-07-01 10:59:44 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-19 18:16:54 +01:00
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:54 +01:00
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-19 15:12:27 +05:30
|
|
|
|
2021-01-21 15:21:50 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2017-06-03 09:38:06 +02:00
|
|
|
|
2015-07-20 15:29:37 +02:00
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2020-05-27 07:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2022-10-20 10:52:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2016-06-14 00:26:22 +02:00
|
|
|
|
2018-06-25 15:51:30 -07:00
|
|
|
|
|
|
|
|
|
2016-06-14 00:26:22 +02:00
|
|
|
|
|
|
|
|
|
2012-08-03 02:19:09 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2016-06-14 00:26:22 +02:00
|
|
|
|
|
|
|
|
|
2010-08-31 12:00:50 +02:00
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2010-08-31 12:00:50 +02:00
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
2016-06-14 00:26:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
|
|
|
|
|
drbd: if there is no good data accessible, writes should be IO errors
If DRBD lost all path to good data,
and the on-no-data-accessible policy is OND_SUSPEND_IO,
all pending and new IO requests are suspended (will block).
If that setting is OND_IO_ERROR, IO will still be completed.
READ to "clean" areas (e.g. on an D_INCONSISTENT device,
and bitmap indicates a block is already in sync) will succeed.
READ to "unclean" areas (bitmap indicates block is out-of-sync),
will return EIO.
If we are already D_DISKLESS (or D_FAILED), we also return EIO.
Unfortunately, on a former R_PRIMARY C_SYNC_TARGET D_INCONSISTENT,
after replication link loss, new WRITE requests still went through OK.
The would also set the "out-of-sync" bit on their way, so READ after
WRITE would still return EIO. Also, the data generation UUIDs had not
been bumped, we would cause data divergence, without being able to
detect it on the next sync handshake, given the right sequence of events
in a multiple error scenario and "improper" order of recovery actions.
The right thing to do is to return EIO for all new writes,
unless we have access to good, current, D_UP_TO_DATE data.
The "established best practices" way to avoid these situations in the
first place is to set OND_SUSPEND_IO, or even do a hard-reset from
the pri-on-incon-degr policy helper hook.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-06-14 00:26:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drbd: introduce drbd_recv_header_maybe_unplug
Recently, drbd_recv_header() was changed to potentially
implicitly "unplug" the backend device(s), in case there
is currently nothing to receive.
Be more explicit about it: re-introduce the original drbd_recv_header(),
and introduce a new drbd_recv_header_maybe_unplug() for use by the
receiver "main loop".
Using explicit plugging via blk_start_plug(); blk_finish_plug();
really helps the io-scheduler of the backend with merging requests.
Wrap the receiver "main loop" with such a plug.
Also catch unplug events on the Primary,
and try to propagate.
This is performance relevant. Without this, if the receiving side does
not merge requests, number of IOPS on the peer can me significantly
higher than IOPS on the Primary, and can easily become the bottleneck.
Together, both changes should help to reduce the number of IOPS
as seen on the backend of the receiving side, by increasing
the chance of merging mergable requests, without trading latency
for more throughput.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-08-29 10:20:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
drbd: introduce drbd_recv_header_maybe_unplug
Recently, drbd_recv_header() was changed to potentially
implicitly "unplug" the backend device(s), in case there
is currently nothing to receive.
Be more explicit about it: re-introduce the original drbd_recv_header(),
and introduce a new drbd_recv_header_maybe_unplug() for use by the
receiver "main loop".
Using explicit plugging via blk_start_plug(); blk_finish_plug();
really helps the io-scheduler of the backend with merging requests.
Wrap the receiver "main loop" with such a plug.
Also catch unplug events on the Primary,
and try to propagate.
This is performance relevant. Without this, if the receiving side does
not merge requests, number of IOPS on the peer can me significantly
higher than IOPS on the Primary, and can easily become the bottleneck.
Together, both changes should help to reduce the number of IOPS
as seen on the backend of the receiving side, by increasing
the chance of merging mergable requests, without trading latency
for more throughput.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-08-29 10:20:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
drbd: introduce drbd_recv_header_maybe_unplug
Recently, drbd_recv_header() was changed to potentially
implicitly "unplug" the backend device(s), in case there
is currently nothing to receive.
Be more explicit about it: re-introduce the original drbd_recv_header(),
and introduce a new drbd_recv_header_maybe_unplug() for use by the
receiver "main loop".
Using explicit plugging via blk_start_plug(); blk_finish_plug();
really helps the io-scheduler of the backend with merging requests.
Wrap the receiver "main loop" with such a plug.
Also catch unplug events on the Primary,
and try to propagate.
This is performance relevant. Without this, if the receiving side does
not merge requests, number of IOPS on the peer can me significantly
higher than IOPS on the Primary, and can easily become the bottleneck.
Together, both changes should help to reduce the number of IOPS
as seen on the backend of the receiving side, by increasing
the chance of merging mergable requests, without trading latency
for more throughput.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-08-29 10:20:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
2013-12-04 12:07:09 +01:00
|
|
|
|
2023-03-30 12:27:43 +02:00
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
|
|
|
|
|
2013-12-04 12:07:09 +01:00
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
2013-12-04 12:07:09 +01:00
|
|
|
|
2011-01-28 15:53:51 +01:00
|
|
|
|
2012-03-26 20:12:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-27 14:08:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2016-07-19 11:28:41 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-11-28 15:04:49 +01:00
|
|
|
|
2011-05-31 14:33:49 +02:00
|
|
|
|
2010-05-27 15:07:43 +02:00
|
|
|
|
2012-07-31 09:31:11 +02:00
|
|
|
|
|
|
|
|
|
2012-08-07 06:42:09 +02:00
|
|
|
|
|
|
|
|
|
2011-05-31 14:33:49 +02:00
|
|
|
|
2010-05-27 15:07:43 +02:00
|
|
|
|
2011-05-31 14:33:49 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2010-10-27 12:21:30 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
drbd: if there is no good data accessible, writes should be IO errors
If DRBD lost all path to good data,
and the on-no-data-accessible policy is OND_SUSPEND_IO,
all pending and new IO requests are suspended (will block).
If that setting is OND_IO_ERROR, IO will still be completed.
READ to "clean" areas (e.g. on an D_INCONSISTENT device,
and bitmap indicates a block is already in sync) will succeed.
READ to "unclean" areas (bitmap indicates block is out-of-sync),
will return EIO.
If we are already D_DISKLESS (or D_FAILED), we also return EIO.
Unfortunately, on a former R_PRIMARY C_SYNC_TARGET D_INCONSISTENT,
after replication link loss, new WRITE requests still went through OK.
The would also set the "out-of-sync" bit on their way, so READ after
WRITE would still return EIO. Also, the data generation UUIDs had not
been bumped, we would cause data divergence, without being able to
detect it on the next sync handshake, given the right sequence of events
in a multiple error scenario and "improper" order of recovery actions.
The right thing to do is to return EIO for all new writes,
unless we have access to good, current, D_UP_TO_DATE data.
The "established best practices" way to avoid these situations in the
first place is to set OND_SUSPEND_IO, or even do a hard-reset from
the pri-on-incon-degr policy helper hook.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2016-06-14 00:26:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-30 12:27:43 +02:00
|
|
|
|
|
|
|
|
|
drbd: fix potential data divergence after multiple failures
If we get an IO-error during an activity log transaction,
if we failed to write the bitmap of the evicted extent,
we must not write the transaction itself.
If we failed to write the transaction,
we must not even submit the corresponding bio,
as its extent is not yet marked in the activity log.
Otherwise, if this was a disconneted Primary (degraded cluster), which
now lost its disk as well, and we later re-attach the same backend
storage, we possibly "forget" to resync some parts of the disk that
potentially have been changed.
On the receiving side, when receiving from a peer with unhealthy disk,
checking for pdsk == D_DISKLESS is not enough, we need to set out of
sync and do AL transactions for everything pdsk < D_INCONSISTENT on the
receiving side.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
2010-10-18 23:04:07 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drbd: introduce drbd_recv_header_maybe_unplug
Recently, drbd_recv_header() was changed to potentially
implicitly "unplug" the backend device(s), in case there
is currently nothing to receive.
Be more explicit about it: re-introduce the original drbd_recv_header(),
and introduce a new drbd_recv_header_maybe_unplug() for use by the
receiver "main loop".
Using explicit plugging via blk_start_plug(); blk_finish_plug();
really helps the io-scheduler of the backend with merging requests.
Wrap the receiver "main loop" with such a plug.
Also catch unplug events on the Primary,
and try to propagate.
This is performance relevant. Without this, if the receiving side does
not merge requests, number of IOPS on the peer can me significantly
higher than IOPS on the Primary, and can easily become the bottleneck.
Together, both changes should help to reduce the number of IOPS
as seen on the backend of the receiving side, by increasing
the chance of merging mergable requests, without trading latency
for more throughput.
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2017-08-29 10:20:32 +02:00
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
2015-01-16 17:41:55 +01:00
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
|
|
|
|
|
2023-03-30 12:27:43 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2013-12-04 12:07:09 +01:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
|
|
|
|
|
2022-12-01 12:03:49 +01:00
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2012-09-27 15:19:38 +02:00
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2012-01-24 17:19:42 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2017-05-11 10:21:46 +02:00
|
|
|
|
2013-12-04 12:07:09 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2013-12-04 12:07:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 17:04:14 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
|
|
|
|
|
2021-01-21 15:21:50 +01:00
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
2021-01-21 15:21:50 +01:00
|
|
|
|
2013-03-19 18:16:50 +01:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-22 18:14:40 -06:00
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
|
|
|
|
|
2013-03-22 18:14:40 -06:00
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 12:32:01 +01:00
|
|
|
|
2013-12-20 11:22:13 +01:00
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-22 18:14:40 -06:00
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
2013-03-22 18:14:40 -06:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
2017-08-29 10:20:33 +02:00
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2017-08-29 10:20:33 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
|
|
|
|
|
2013-03-22 18:14:40 -06:00
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
2017-08-29 10:20:33 +02:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
2017-08-29 10:20:33 +02:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-29 10:20:34 +02:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
|
|
|
|
|
2013-03-22 18:14:40 -06:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-22 18:14:40 -06:00
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
2013-03-22 18:14:40 -06:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-19 18:16:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:58 +01:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-19 18:16:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-03-19 18:16:58 +01:00
|
|
|
|
|
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2013-11-22 12:52:03 +01:00
|
|
|
|
2013-03-19 18:16:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
2013-03-19 18:16:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
2014-02-11 11:15:36 +01:00
|
|
|
|
2014-05-07 22:41:28 +02:00
|
|
|
|
2013-03-22 18:14:40 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 13:12:24 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2021-01-24 11:02:34 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2022-07-27 12:22:55 -04:00
|
|
|
|
2023-01-04 08:51:19 -07:00
|
|
|
|
|
|
|
|
|
2015-04-23 22:37:18 -07:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-27 16:23:33 +02:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2021-01-21 15:21:50 +01:00
|
|
|
|
2009-09-25 16:07:19 -07:00
|
|
|
|
|
|
|
|
|
2015-02-19 13:54:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-17 20:33:01 -07:00
|
|
|
|
2011-03-01 11:08:28 +01:00
|
|
|
|
2025-05-09 07:51:14 +02:00
|
|
|
|
|
|
|
|
|
2011-05-31 14:33:49 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2011-04-19 17:10:19 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2011-06-29 14:06:08 +02:00
|
|
|
|
2012-04-25 11:46:14 +02:00
|
|
|
|
2015-02-19 13:54:11 +01:00
|
|
|
|
2011-03-01 11:08:28 +01:00
|
|
|
|
2011-04-19 17:10:19 +02:00
|
|
|
|
2011-05-30 16:32:41 +02:00
|
|
|
|
2015-02-19 13:54:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-05 15:38:59 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-29 14:06:08 +02:00
|
|
|
|
2011-04-19 17:10:19 +02:00
|
|
|
|
2011-03-01 11:08:28 +01:00
|
|
|
|
2015-02-19 13:54:11 +01:00
|
|
|
|
|
|
|
|
|
2011-06-29 14:06:08 +02:00
|
|
|
|
|
|
|
|
|
2012-04-25 11:46:14 +02:00
|
|
|
|
2011-03-01 11:08:28 +01:00
|
|
|
|
|
|
|
|
|
2012-04-25 11:46:14 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2012-04-25 11:46:14 +02:00
|
|
|
|
2011-07-07 14:19:42 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
2015-02-19 13:54:11 +01:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2015-02-19 13:54:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-01 11:08:28 +01:00
|
|
|
|
2015-02-19 13:54:11 +01:00
|
|
|
|
2014-11-10 17:21:14 +01:00
|
|
|
|
2015-02-19 13:54:11 +01:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2011-07-03 17:53:52 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2011-06-29 14:06:08 +02:00
|
|
|
|
2014-04-28 18:43:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 18:43:31 +02:00
|
|
|
|
2013-11-22 13:00:12 +01:00
|
|
|
|
2014-09-11 14:29:08 +02:00
|
|
|
|
2011-07-03 13:26:43 +02:00
|
|
|
|
2011-03-01 11:08:28 +01:00
|
|
|
|
