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@xxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
