On Mon, 27 Apr 2009, Alasdair G Kergon wrote: > On Mon, Apr 27, 2009 at 10:48:37PM +0100, Alasdair G Kergon wrote: > > On Mon, Apr 20, 2009 at 04:01:11AM -0400, Mikulas Patocka wrote: > > > Flush supoprt for dm-delay target. > > > @@ -281,6 +282,8 @@ static int delay_map(struct dm_target *t > > > bio->bi_sector = dc->start_write + > > > (bio->bi_sector - ti->begin); > > In fact, does bi_sector have a meaningful value within > the context of a specific target any more when processing > a barrier flush, or is it a bug if a target attempts to access it? > (For example, it could be set to ti->begin or 0.) > > I think the situation deserves defining in a comment. > > (Maybe we will remove "- ti->begin" from all the mapping functions one day. > Not mixed in with this patch set though.) The code is correct as it is. For example, if you have first 10 sectors mapped on linear target and next sectors mapped on delay target, you must subtract 10 from the value (-ti->begin) and add the start offset dc->start_write. If you map the whole device as one target, this is meaningless. But if you map more targets into one table, this arithmetics is required. The difference is the zero-barrier flush request --- it should have bi_sector always 0. Mikulas > Alasdair > -- > agk@xxxxxxxxxx > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
