[RFC PATCH 0/4] dm core: full barrier support

* [RFC PATCH 0/4] dm core: full barrier support
@ 2008-07-08 16:48 Milan Broz
  2008-08-06 10:05 ` Nikola Ciprich
  0 siblings, 1 reply; 4+ messages in thread
From: Milan Broz @ 2008-07-08 16:48 UTC (permalink / raw)
  To: Alasdair G Kergon; +Cc: device-mapper development

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
--
mbroz@redhat.com

^ permalink raw reply	[flat|nested] 4+ messages in thread