On Mon, Feb 16, 2004 at 02:30:47PM +0100, Jens Axboe wrote:
> Seems there's an extra problem here, the nr_requests vs depth problem
> should not be too problematic unless you have heavy random io. Doesn't
> look like dm is reordering (bio_list_add() adds to tail,
> flush_deferred_io() processes from head. direct queueing doesn't look
> like it's reordering). Can the dm folks verify this?
Ordering is certainly maintained for the simple targets (linear,
striped). Snapshots and mirroring still need some work in this
regard, but I don't think these are begin used for the tests.
The place that I am expecting dm to cause poor performance is due to
this bit of stupidity in dm-table.c. It's on my TODO list, but is not
getting to the op since no-one seems to be complaining about it yet.
/* FIXME: Device-Mapper on top of RAID-0 breaks because DM
* currently doesn't honor MD's merge_bvec_fn routine.
* In this case, we'll force DM to use PAGE_SIZE or
* smaller I/O, just to be safe. A better fix is in the
* works, but add this for the time being so it will at
* least operate correctly.
*/
if (q->merge_bvec_fn)
rs->max_sectors =
min_not_zero(rs->max_sectors,
(unsigned short)(PAGE_SIZE >> 9));
- Joe
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
