Re: [linux-lvm] Re: IO scheduler, queue depth, nr_requests

[Joe Thornber <thornber@redhat.com>]

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