RFC dm core: full barrier support

Hi,

there was several discussions about supporting barriers in device-mapper.

I wrote this code some time ago, but it never reached dm-devel tree. Take this more like RFC and experimental approach
- maybe there is better way how to handle it.
Anyway this implementation works in my tests and is relatively simple.

[RFC PATCH 1/4] dm core: remove unused code
- just remove never used code, already sent some time ago in another patchset

[RFC PATCH 2/4] dm core: add support for empty barriers
- the core implementation of empty barrier support
- implementation for stripe target

[RFC PATCH 3/4] dm core: add support for barrier bio with payload
- tranform payload to sequence of data bio + empty barrier

[RFC PATCH 4/4] dm core: wait for barrier in process in suspend
- try to solve the problem that we cannot suspend device during processing of barrier.

Notes to implementation:

* Patches are generated with previously applied bvec_merge patches from dm-devel tree (but it should work even without them) (removing unnecessary bio split was part of solution)

* ignoring multipath for now, but it should probably process barriers correctly in multipath target

* barrier is expensive operation, so it should be used very rarely, processing (and cost) in DM is equivalent to suspending device

* There are several types of barrier implementation
in hw drivers (DRAIN,TAGGING, ...) but DM doesn't care about it - I think that sending zero-sized barrier to low-lever driver is enough to allow its internal logic to decide what to do.

* DM target is responsible for processing barrier for its devices. (barrier is sent per target not per device).

- Only targets know which devices are related to barrier request, and dm-core have no functionality to decide which devices are used in specific targets (!)

- Most of targets will probably need no special code to handle zero-sized barrier

- implementation is simpler, we can e.g. disable barriers for some type of target (and implement it later)

- it must process correctly mapping table reloads

* DM always send zero-sized barriers, barriers with payload are converted to non-barrier bios with payload
+ subsequent zero-size barrier

* All preceding IOs must be processed when barrier is issued
- All barriers is processed with down_write(io_lock) locked. Because bios are internally queued per process (in *make_request) this is sufficient to ensuring that all previous IOs are submitted by DM (dm_request runs with down_read, so barrier request will wait till all "readers" are done).

- Moreover, after submitting zero barrier, code waits till all processing IOs (per md) are finished before releasing flag. It waits even for reads and barrier itself now.

* After processing all requests (including all barrier clones) the queued IOs are flushed.
- If there is another barrier in queue, operation continues without clearing BLOCK_IO flag (this flag is cleared only when whole queue if flushed and no new barrier is on-the-fly).

* Some targets do not need changes (linear), others need review but should work in general (mirror, crypt, ...)

Milan
--
[email protected]