[dm-devel] [RFC PATCH 0/4] dm core: full barrier support
Milan Broz
mbroz at redhat.com
Tue Jul 8 16:48:53 UTC 2008
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 at redhat.com
More information about the dm-devel
mailing list