FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 06-18-2011, 03:57 PM
Krzysztof Błaszkowski
 
Default newbie question regarding target_type's map callback

Hello,

I designed a target where constructor sets split_io. During tests on
local filesystem (ext3) with dbench (150 processes, dbench is modified
that way it leaves its files at exit) (kernels: 2.6.33.7 and 2.6.39.1) i
noticed that amount of bios can reach level of 250k.

I was thinking that i can use "throttling" facility if i added following
section in my map function:

if (mytgt->inbox.pending > 180000) {
wait_event_timeout(mytgt->throttling.wait, (mytgt->inbox.pending <
150000), 2 * HZ);
}

and
if (mytgt->inbox.pending < 150000)
wake_up_all(&mytgt->throttling.wait);
in function which frees resources for given bio from "inbox".

I noticed that after adding this "throttling" feature it turned out that
filesystem is inconsistent after single test run (but throttling works
of course. inbox.pending never exceeds 180k + 3 .. 7, i guess it is
amount of logical cores).

Interesting is that without the facility filesystem and dm are
periodically stalled as long as my target confirms some number of
pending bios but filesystem corruption doesn't happen.

I was thinking that any "upper" bio which is split into bios of size not
bigger than split_io is completed only when all these small bios are
ended with bio_endio() thus changing order of small bios execution
(delaying some of them) doesn't matter.

Was i right ?
if i was then what could be reasons of corrupting filesystem because of
"throttling" feature?
or maybe i missed something, did i ?

I was thinking about these following also:
Can someone explain benefits from using map vs map_rq ?
Does DM_MAPIO_REQUEUE (map callback) work properly ? I noticed that dm
from 2.6.33.7 seems to not handle this right and filesystem complains on
IOs with error code.

Thanks for giving me clues on these above.

Regards,

--
Krzysztof Blaszkowski

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 06-19-2011, 01:48 AM
Alasdair G Kergon
 
Default newbie question regarding target_type's map callback

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.

What is your target trying to do?
(Why is split_io important? Did you implement a merge fn?)

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 06-19-2011, 12:33 PM
Krzysztof Błaszkowski
 
Default newbie question regarding target_type's map callback

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.

How about DM_MAPIO_REQUEUE ?


>
> What is your target trying to do?

it is just a simple model target now which passes back requests from
inbox queue to dm_io() on a single backend dev in context of target's
work queue.

> (Why is split_io important?

well, for same reason like dm-stripe. i may need this in the future for
switching backend devices dynamically according to bio LBA. This is why
i want to have a bio of size not bigger than split_io.


> Did you implement a merge fn?)


no, i didn't. i don't know a purpose of merge fn.

I can see that e.g. dm-stripe doesn't use this callback in 2.6.33 kernel
while dm-stripe from 2.6.39 uses it.

furthermore dm-linear from 2.6.33 and .39 utilize .merge but split_io is
0.

>
> Alasdair
>


--
Krzysztof Blaszkowski

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 06-22-2011, 01:09 PM
Krzysztof Błaszkowski
 
Default newbie question regarding target_type's map callback

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

Thread Tools




All times are GMT. The time now is 09:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org