From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Broz Subject: [RFC PATCH 0/4] dm core: full barrier support Date: Tue, 08 Jul 2008 18:48:53 +0200 Message-ID: <48739A75.1070807@redhat.com> Reply-To: device-mapper development Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Alasdair G Kergon Cc: device-mapper development List-Id: dm-devel.ids 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