block/drbd/drbd_receiver.c

199 	   they are sent in order over the wire, they have to finish
346 You must not have the req_lock:
571  *   listen(2) or connect(2) calls in order to have it take effect.
917  *   1 yes, we have a valid connection
921  *  -2 We do not have a network config...
1225 		/* If we have nothing in the receive buffer now, to reduce
1227 		 * quickly as possible, and let remote TCP know what we have
1394 			/* FIXME: dec unacked on connection, once we have
1485  * Drivers have to "announce" q->limits.max_write_zeroes_sectors, or it
1546 		 * layers are below us, some may have smaller granularity */
1626  * Returns 0 if all bios have been submitted,
1628  * -ENOSPC (any better suggestion?) if we have not been able to bio_add_page a
1683 	 * should have been mapped to a "drbd protocol barrier".
1843  * both trim and write same have the bi_size ("data len to be affected")
1896 	 * we sometimes have to double check. */
2280 	 * For 24-bit wrap-around, we would have to shift:
2335  * packet traveling on msock, they are still processed in the order they have
2345  * Assume we have a 10 GBit connection, that is about 1<<30 byte per second,
2346  * about 1<<21 sectors per second. So "worst" case, we have 1<<3 == 8 seconds
2347  * for the 24bit wrap (historical atomic_t guarantee on some archs), and we have
2487 			 * once all overlapping requests have completed.
2523 				 * Requests that have been superseded will
2692 		/* In case we have the only disk of the cluster, */
2730  * to have a short time average so we can react faster.
2880 		/* If at some point in the future we have a smart way to
2974 	 * even if we have to sleep below. */
3484 		drbd_alert(device, "To resolve this both sides have to support at least protocol %d and feature flags 0x%x\n",
3489 		drbd_alert(device, "To resolve this both sides have to support at least protocol %d\n", -hg - 1000);
4159 		 * it may have been larger than mine all along...
4169 		 * Unless of course he does not have a disk himself.
4188 			 *  - I don't have a current size myself
4190 			 *  - I do have a current size, am Secondary,
4192 			 *  - I do have a current size, am Primary,
4212 			/* we have different sizes, probably peer
4441 		 * It may have changed syncer-paused flags, however, so we
4467 	 * and this happens while the peer still thinks we have a sync going on,
4485 	 * If this node does not have good data, was already connected, but
4511 		/* if we have both been inconsistent, and the peer has been
4697 	int have;
4706 	for (have = bits; have > 0; s += rl, toggle = !toggle) {
4720 		if (have < bits) {
4722 				have, bits, look_ahead,
4732 		have -= bits;
4734 		bits = bitstream_get_bits(&bs, &tmp, 64 - have);
4737 		look_ahead |= tmp << have;
4738 		have += bits;
4763 	 * but have been dropped as this one turned out to be "best"
4889 		/* admin may have requested C_DISCONNECTING,
4890 		 * other threads may have noticed network errors */
5174 	/* We do not have data structures that would allow us to
5176 	 *  * On C_SYNC_TARGET we do not have any data structures describing
5177 	 *    the pending RSDataRequest's we have sent.
5201 	   might have issued a work again. The one before drbd_finish_peer_reqs() is
5205 	/* need to do it again, drbd_finish_peer_reqs() may have populated it
5275  *   1 yes, we have a valid connection
5762 		/* In Protocol B we might already have got a P_RECV_ACK