linux.git/drivers/block/drbd/drbd_worker.c, branch v3.17

drbd: debugfs: add callback_history

2014-07-10T16:35:18+00:00

Add a per-connection worker thread callback_history
with timing details, call site and callback function.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: track timing details of peer_requests

2014-07-10T16:35:14+00:00

To be able to present timing details in debugfs,
we need to track preparation/submit times of peer requests.

Track peer request flags early,
before they are put on the epoch_entry lists.

Waiting for activity log transactions may be a major latency factor.
We want to be able to present the peer_request state accurately in
debugfs, and what it is waiting for.

Consistently mark/unmark peer requests with EE_CALL_AL_COMPLETE_IO.
Set it only *after* calling drbd_al_begin_io(),
clear it as soon as we call drbd_al_complete_io().

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: improve throttling decisions of background resynchronisation

2014-07-10T16:35:13+00:00

Background resynchronisation does some "side-stepping", or throttles
itself, if it detects application IO activity, and the current resync
rate estimate is above the configured "cmin-rate".

What was not detected: if there is no application IO,
because it blocks on activity log transactions.

Introduce a new atomic_t ap_actlog_cnt, tracking such blocked requests,
and count non-zero as application IO activity.
This counter is exposed at proc_details level 2 and above.

Also make sure to release the currently locked resync extent
if we side-step due to such voluntary throttling.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: gather detailed timing statistics for drbd_requests

2014-07-10T16:35:11+00:00

Record (in jiffies) how much time a request spends in which stages.
Followup commits will use and present this additional timing information
so we can better locate and tackle the root causes of latency spikes,
or present the backlog for asynchronous replication.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: track meta data IO intent, start and submit time

2014-07-10T16:35:10+00:00

For diagnostic purposes, track intent, start time
and latest submit time of meta data IO.

Move separate members from struct drbd_device
into the embeded struct drbd_md_io.
s/md_io_(page|in_use)/md_io.\1/

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: consistently use list_add_tail for peer_request tracking

2014-07-10T16:35:08+00:00

Keep the epoch entry lists (active_ee, read_ee, sync_ee, ...)
consistently "oldest first".  That way finding the oldest not yet
successfully processed request is simply list_first_entry_or_null.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: add drbd_queue_work_if_unqueued helper

2014-07-10T16:35:07+00:00

We sometimes do
    if (list_empty(&w.list))
	drbd_queue_work(&q, &w.list);

Removal (list_del_init) may happen outside all locks, after all
pending work entries have been moved to an on-stack local work list.

For not dynamically allocated, but embeded, work structs,
we must avoid to re-add until it really was removed.

Move that list_empty check inside the spin_lock(&q->q_lock)
within the helper function, and change to list_empty_careful().

This may have been the reason for a list_add corruption
inside drbd_queue_work().

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: drbd_rs_number_requests: fix unit mismatch in comparison

2014-07-10T16:35:06+00:00

We try to limit the number of "in-flight" resync requests.
One condition for that is the amount of requested data should not exceed
half of what can be covered by our "max-buffers" setting.

However we compared number of 4k pages with number of in-flight 512 Byte
sectors, and this extra throttle triggered much earlier than intended.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: improve resync request throttling due to sendbuf size

2014-07-10T16:35:04+00:00

If we throttle resync because the socket sendbuffer is filling up,
tell TCP about it, so it may expand the sendbuffer for us.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: implement csums-after-crash-only

2014-07-10T16:35:00+00:00

Checksum based resync trades CPU cycles for network bandwidth,
in situations where we expect much of the to-be-resynced blocks
to be actually identical on both sides already.

In a "network hickup" scenario, it won't help:
all to-be-resynced blocks will typically be different.

The use case is for the resync of *potentially* different blocks
after crash recovery -- the crash recovery had marked larger areas
(those covered by the activity log) as need-to-be-resynced,
just in case. Most of those blocks will be identical.

This option makes it possible to configure checksum based resync,
but only actually use it for the first resync after primary crash.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg