Hello again, On Sun, 2011-06-19 at 02:48 +0100, Alasdair G Kergon wrote: > All I can suggest is studying the existing upstream targets to > understand better how they work and perhaps avoid problems like the ones > you are seeing. I would like rather to discuss operation principles than study code like e.g.: dm-raid1, dm-hash-region, dm-log and dm (although i've done it a bit and not everything is clear to me) Regarding ordering i found this: http://markmail.org/message/qa7weh3gdorqw7p4#query:+page:1 +mid:djfewqc645ldatf2+state:results There was one note i reckon is important to me: " Ordering is certainly maintained for the simple targets (linear, striped). Snapshots and mirroring still need some work in this regard, .. " And how does this look like nowadays ? According to dm-raid1 example i changed my model of target. And now map function adds bios to bio list which is drained later in worker thread in order bios appeared in map. In this worker i do update block bookkeeping table - set e.g. first bio and queue more bios for same block lba. I reckon this map queue may be more safe than updating bookkeeping table directly in map because worker uses a list where bios order is predefined and doesn't depend on e.g. map preemption. The bookkeeping table is updated again in dm's end_io callback where, i reckon, bio is considered to be done. I do not use dm_io() callback for updating bookkeeping table, only bio_endio() is used there to complete bio sent to map function. I was thinking about following problem: let's suppose there are e.g. 3 scsi requests, simple queue (e.g. write10, read10, write10), they arrived in time: Rq1 which dm will divide into blocks {A1, B1, C1, D1}, Rq2 : {B2, C2}, and Rq3 of {A3-F3}, index next to Rq stands for order in time. Lower index means earlier request. Same letter stands for a block with the same block lba. My concern is: if these blocks A1, B1, C1, .., B2, A3, .. F3 will arrive in correct order in map function ? Is map function serialized by some means inside dm ? (can map preemption change order of seeing these block by dm target ?) And is following thesis safe ? (that's very important) : #1. it is always true that data corruption due to wrong reordering will not happen if dm target will preserve time order of blocks (of the same lba) passed back to dm_io always. e.g. {B1, B2, B3} or {C1, C2, C3} and e.g. {B2, B1, B3} is example of dm target failure. the above stands for that real sequence of passing back these blocks to dm_io may look like this: A1, B1, C1, B2, C2, C3, B3, A3 ... or e.g. A1, D1, B1, B2, B3, D2, A3 or any other similar. What will be order of completing Rq1, Rq2, Rq3 for any possible combination of block processing with exception according to thesis #1 > > What is your target trying to do? > (Why is split_io important? Did you implement a merge fn?) > dm-raid1 doesn't use merge fn (neither me). > Alasdair > Regards, -- Krzysztof Blaszkowski -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
